Adopting new technology is not just about building a “Hello World” Application but testing its capabilities to match precise requirements for real-world situations. After a fair amount of playing and digging in, this article aims to provide an overview about Acropolis. At the same time, I will suggest solutions to enhance some of the drawbacks identified in the current build that I outline in this paper.

Rapid Application Development

Acropolis provides an integrated designer within Visual Studio Orcas where we can drop “Parts” and set up their properties. This is an excellent way for “Beginners” or for Quick and Dirty purpose. Unfortunately, we stick on this design when we start to apply enterprise productivity. Let’s me take an example; an application that loads different workspace depending on “User Profile” can’t be integrated in Acropolis NavigationManager. We need to call manually the method “BindToCollection” on “Microsoft.Acropolis.PartFx.NavigationManager” because when “AcropolisApplication” is activated, it performs the “ChildParts” binding on the NavigationManager.

Another RAD orientation is to associate “Part” of its “View” with a custom Attribute “ViewExtensionInfo”. A more convenient way to address this would be to use an external mapping file.

At least, Services Dependencies concept is pretty cool by design, but in Real World application, we don’t know in advance all the components involved in a composite application.

It makes sense that most efforts are driven towards RAD. Acropolis is at a very early stage and probably focused on a seduction phase, it has to gain its audience. This means that it targets a wider audience and it uses WPF more for its simple and sexy look and feel, but it seems that is done to the detriment of Enterprise reality.

On the road to Enterprise Productivity

The current build of Acropolis is RAD oriented but it provides many opportunities to be extended.

Extensibility

One of the beautiful things that Acropolis provides is a real reusable framework that comes from CAB and so on. This API’s is very useful when we want to provide custom implementations on top of Acropolis. This means that we can participate to Acropolis effort and provide an enterprise orientation to ensure its specific requirements are addressed.

Theme Manager

Implementing custom theme is done by inheriting from “Microsoft.Acropolis.Windows.Theme”. Themes registration can be done by the method “AcropolisApplication.RegisterThemeAssembly” by specifying your theme object type as parameter, the registration have to be done when “AcropolisApplication” starts (override the method “OnStartup”). This is the easiest way but makes it hard coded. On the other hand, you can declare your themes by configuration as follow:

<configuration>
  <configSections>
    <sectionGroup name="microsoft.acropolis">
      <section name="themeInfo" 
               type="Microsoft.Acropolis.ThemeInfoConfigSection,Microsoft.Acropolis.PartFx,Version=2.0.0.0,Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
    </sectionGroup>
  </configSections>
  <microsoft.acropolis>
    <themeInfo>
      <themes>
        <add assembly="[AssemblyName]" type="[Namespace.ThemeObjectType]"/>
      </themes>
    </themeInfo>
  </microsoft.acropolis>
</configuration> 

The theme configuration above can be loaded by “ConfigFileThemeProvider” class that implements “IThemeProvider”. This class loads all the types implementing the “ITheme” interface when the type attribute on “theme\add” element is a star (“*”), otherwise, it loads the type specified explicitly. Once again, we need to register manually when on Application starts by calling “ThemeService.Instance.RegisterThemes”. I suggest implementing an automatic theme registration mechanism when it is specified by configuration. In addition, having a property “IsDefault” on “ThemeConfigElement” allows specifying theme externally without setting “Theme” property on the “AcropolisApplication”.

Part Model

Part Composition

Acropolis Composition applies a “Composite” Pattern to represent a hierarchical object model for “Part”. However, the user Interface representation within WPF doesn’t provide by default a child Parts chaining, it has to be done manually. It should be best to provide this behavior by default within the Composition Engine.

With Acropolis, there is no limit to add child parts. I’m very anxious in regards to this behavior because it might generate issues on how developers make their application. What I mean by this is that Part is not only focused on the business case it addresses, it also has to be aware of its “environment” in the sense that it has to take into account the layout or the window it is loaded in.

To address this, I suggest a new Part Composition Object Model that allow for anyone to compose an application layout based on “PartView”.

First, let’s make sure we’re all in the same page by presenting the new Object Model in the figure below:

On the left side:

1. “Workspace” represents the Root Level of your application; basically, it’s a Window. Workspace has one or many Layout child,
2. “Layout” represents a single active view on the Workspace, Layout has one or many Slot child,
3. “Slot” represents a zone (like a canvas), Slot has one or many Component,
4. “Component” represents the Developers Unit of Work, it can have a child that we can call “Sub-Component”

On the right side:

You notice that it’s the UI Control mapping for our Part Object Model. Don’t worry, this model is not really different than the one provided by default by Acropolis provides. The goal is the same but the approach is a little bit different using WPF Control. So, let’s talk about the advantage of this model, several capabilities come to us:

1. Parts Composition is not only for the Developers but also for Designer. Both Layout and Slot aims to compose your application layout design, allowing Developers to work only on the Component View.
2. Allows a clean composition of Parts
3. Layout and Slot allow defining a “Scope” level because they act as a “Container”. This is an important feature in all cases to apply “Event Notification”, “Data”, “Services” and so on.
4. Avoid confusion about using “ActiveParts” versus “ActivePart” Navigation Property. By using WPF “ItemsControl” Control, the only one thing we do is to call the “ActiveParts” property without taking care about children. Now, the big question is: How can I apply a Layout Pattern on Workspace, LayoutChildParts and SlotChildParts? The answer is very simple, WPF is powerful; ItemsControl provides a property called “ItemsPanelTemplate”, this property allows defining any kind of layout (LayoutPane in Acropolis) like Tab, Grid, Stack, …

Screenshots are more meaningful than a long sentence:

Figure 1: Single (Main Layout) Layout on a Workspace, Slots (Menu, Navigation and Main Content) are in a “StackPanel” with Vertical orientation.

Figure 2: Single (Main Layout) Layout on a Workspace, Slots (menu, Navigation and Main Content) are in a “TabPanel”.

Figure 3: Layouts (Main Layout and Second Layout) are in a “TabPanel” on a Workspace, Slots are in a “StackPanel” with Vertical orientation.

Part Communication

Building Composite application tends to avoid thigh coupling between Parts. Unfortunately, NavigationManager is not going this way with NavigateTo method that implies a dependency between two parts. The alternative is to provide a custom NavigationManager implementation.

Part provides a set of features as “Services Dependencies”, “Data Publishing” and “EventNotification”. This is sounds good but the lack is in the PartView side that consumes them. Of course, by code behind, we can access the Part via “IPartViewContract”, right. Now, what about XAML? It would be more convenient to be able to develop parts without requiring registering events or calling external services in code behind.

Part Life Cycle

One of the big surprise with Acropolis is there is no real life cycle applied on Part or on Acropolis Application. It is very important to have a well known, pre defined, life cycle applied on all components. I suggest having something like ASP.NET’s Life Cycle; it simplifies the implementation of custom code, and allows knowing exactly what happen behind the scene at each and every stages of the execution. By experience, doing something as a black box induces some frustration and slows down technology adoption.

Conclusion

Personally, I see Acropolis taking the RAD approach and not target industrialization at this stage. Acropolis is heavily based on the famous composite UI application bloc (CAB) project, so a big impatience is born to get the same level of functionality that CAB provided. I would love to see the next Acropolis releases address more heavily tools and enterprise environment. Will this request be heard? We’ll see...