1 - Introduction

In my previous post, I said that Acropolis provide out of the box 2 kinds of Navigation Model : "SinglePartNavigation" and "MultiPartNavigationManager".

In conclusion of my previous post, I have shortly described the limitations of these 2 navigation models, highlighting the fact that the Navigation between Components is hard coded on the application Design. Therefore, enforcing dependencies between Components.

That's why, it is more convenient to build our own navigation engine. This means that it is required to understand Acropolis Components Life Cycle during an Acropolis Application execution.

2 - Acropolis Application Life Cycle overview

Acropolis Application starts with the "Microsoft.Acropolis.Windows.AcropolisApplication" class that inherits from WFP Application class. When it is initialized, it performs binding (BindToCollection) on both NavigationManager and LifetimeManager as children parts (ChildPartsCollection) as parameters.

The diagram below shows you an overview of Acropolis Application Life Cycle, it is not intended to be detailled further in this post:

3 - Manage User Navigation

Acropolis introduces an extra level of abstraction between a "part" UI and its services with the notion of business contract represented by interfaces. Unfortenatly, this way is not followed by default by the Navigation Manager. Parts are stongly linked between them via the "NavigeTo" method.

3.1 - Acropolis "Part" Life Cycle

"Microsoft.Acropolis.PartFx.Part" is a not a Visual Component. It aims to provide a clean separation between "View" and "Business Behavior". So, how is a Part linked to a View ? The link is acheived by calling "BindToContract" method with "Microsoft.ACropolis.PartFx.IPartViewContract" as parameter. An instance of IPartViewContract is generated during Acropolis Project build, this instance inherits from "Microsoft.Acropolis.PartFx.PartViewContractTearOffBase".

"Part" is being used when ChildPartsCollection is passed through "BindToObjectCollection" method of "NavigationManager". On top of that, Part has been attached on an instance of "Microsoft.Acropolis.ComponentModel.InstanceMoniker". What does it mean ? For the sake of simplicity, it's a kind of metadata for "Part" for my understanding. This instance of moniker is used to deal with NavigationManager to create "PartNavigationItem".

Now, we know what happens behind the scene, so what can we do to make an abstraction between NavigationManager and Part ?

In order to do that, we attach a new property named "Definition" (means as "Family") on the Part. Definition defines a set of Actions (click event on a button) that can be raised. Each Action defines one or more outputs where each one of them is associated to a Definition and a Zone where the output should be displayed.

See below an overview of a XML fragment of Definition:

<?xml version="1.0" encoding="utf-8"?>
  <Project>
    <NavigationItem>
      <Definition name="def1">
      <Action name="action1">
        <Output slot="slot1" partRef="FQN"/>
      </Action>
      <Action name="def2">
        <Output defRef="def10" slot="slot2" partRef="FQN"/>
        <Output defRef="def20" slot="slot1" partRef="FQN"/>
      </Action>
    </Definition>
    <Definition name="def10">
      <Action name="action1">
        <Output slot="slot2" partRef="FQN"/>
      </Action>
    </Definition>
    <Definition name="def20">
      <Action name="action1">
        <Output slot="slot1" partRef="FQN"/>
      </Action>
    </Definition>
  </NavigationItem>
  <SlotNavigationItem>
    <Item name="slot1"/>
    <Item name="slot2"/>
  </SlotNavigationItem>
</Project>

What is the difference bewteen Acropolis default NavigationManagers and UserActionNavigationManager? UserActionNavigationManager is fully driven by external XML data source.

4 - UserActionNavigationManager

In Acropolis, to provide our own NavigationManager we just have to inherit from "Microsoft.Acropolis.PartFx.NavigationManager". That's all. Of course, we need to override the following methods "BindToObjectCollection", "DetachFromObjectCollection" and "NavigateTo" to provide our own navigation logic regarding the XML fragment above.

Remember, see below NavigationManager Life Cycle:

UserActionNavigationManager aims to make the navigation to be dynamic and flexible without hard coding it in your code the navigation logic.

4.1 - Reuse Components in different Scenario

In a Software Industry, Applications must be composed of Components (not an unit of Control) that defines the developper's Unit of Work. Working on component allows developper to focus only on the business target.

4.2 - Test User Navigation Scenario

Who never said that testing application scenario can be a nigthmare ? UserActionNavigationManager might be an answer because, we can replay each Action without requiring the real application. Therefore, we can build navigation scenario with the XML fragment as datasource.

5 - Demo Development

Implementing UserAction Navigation Model on top of Acropolis is on track. The roadmap is not yet defined because it's depending on the next build of Acropolis. I have spent many hours to investigate on current build so I think, something might be changed. This theme was introduced during the session 5 of the .Net Entreprize Realization Day and will be developed further over the next months.

The next post should be a screencast on "UserActionNavigationManager".

Stay tuned... I will post regularly here my findings around Acropolis and more detailled papers on netfxfactory.