First, let me just say that the walk through for building an Acropolis application never actually tells you what the heck an Acropolis application really is. At this point, I'm still a little fuzzy on the entire concept myself. I assume the fuzziness will become more sharp and crisp as time goes by and I do more work with Acropolis.

At this point, it feels as though Acropolis is a layer of abstraction on top of WPF itself. Basically when you build an Acropolis (I'm going to call it AFX , since that's a crapload easier to type, and all the controls are prefixed as "AFX") you get an Application and a main window. Interestingly enough, AFX seems to have support for Document-style (MDI for you "old schoolers" like me...) applications, which WPF alone is sorely lacking. Inside this main window, you can put Parts. Each Part is essentially a re-usable bit of functionality. A Part View is associated with the Part (but is not a partial class of the part... the coupling is far looser than traditional WPF) and is responsible for defining the XAML to render the contents of the part, and can also contain code to dynamically respond to events and manipulate the view.

For example, in the application I just built (which is the RSS reader walkthrough in the CTP docs), there is an RSS Part and a Feed Part. The Feed part renders itself as a combo box of feed history, as well as a button to retrieve a list of RSS items from the feed. The RSS part is responsible for obtaining the information from a given feed, and rendering a list of RSS items.

A couple of things that I found interesting about Acropolis is that it is "skinned". In other words, an Acropolis application looks nothing like a default Vista application. It appears as though the skins are easily configured and you can probably dynamically change the look and feel of your application quite easily.

What I think it boils down to is that using the "part" metaphor, the goal is probably to make it so that client applications are easier to build, easier to unit test (with everything being loosely coupled parts and part views, test controllers should be quite easy to inject), easier to maintain, and more scalable. Only time will tell if Acropolis actually lives up to these goals, but from what I have seen of the CTP so far, those are the exact things that Acropolis is attempting to tackle. Parts have "connection points" and there are these things called command executions which create even more separation. There are also services (think WF services, not WCF or Web Services) that allow individual parts to get data, information, and business logic in a clear, concise way that actually respects separation of concerns.

Here is a screenshot of the application running in Windows XP SP2 on an Orcas build:

Note the many subtle differences in appearance between the Acropolis app and a stock, out of the box WPF app.

tags: acropolis  wpf  orcas
links: digg this    del.icio.us    technorati    reddit