RioterDeckers' HeadQuarter

This new build is really straightforward. As I said before, it is more WPF development now. Congrulations to the Team.

After some hours of developement, the outcome is quiet exciting. My goal is not to provide a rich TreeView control but an evaluation of the effort we can have for a custom control.

What I have done is to match the same class design as WPF, so I implemented the following class:

1. "HeaderedItemsControl" inherits from "ItemsControl"
2. TreeViewItem inherits from HeaderedItemsControl
3. TreeView inherits from ItemsControl
4. Styles and Templates for each controls

See the screenshot below:

As soon as I have implemented the main features, I will post the source code. Below my todo list:

• HierarchicalDataTemplate
• Focus
• Data Binding

In all most of the time, people are using the famous Control "DropDownList" to put a collection of data. But, what happen when this list is so huge and may a performance issue for loading your page? Even if you do that, you are killing your End-Users by scrolling in a long list. It's not a good idea for your Users. So, what we can do? The "Dialog Picker" will be your help.

I think, you will already experience with it when you try looking for Users, Groups, Audiences,... To provide its own in SharePoint 2007 is very simple, it provides you all the needed base classes which you need to inherit from. Let's start implementing step by step each control.

Step 1: Editor

Build a class that inherits from "Microsoft.SharePoint.WebControls.EntityEditorWithPicker". After that you have to provide the type of the dialog (step 2) in the "PickerDialogType" property. Then, provides the separator char in the "EntitySeparator" property.

See below the Editor:

Step 2: Dialog

Build a class that inherits from "Microsoft.SharePoint.WebControls.PickerDialog". This base class is responsible to provide results that matches with the entered text provided in the search input.

See below the dialog:

The base class constructor has 3 parameters:

1. Query (Step 3) contains the logic for retrieving data
2. A Control that display the result set
3. An instance of the Editor (Step 1)

Step 3: Query

Build a class that inherits from "Microsoft.SharePoint.WebControls.SimpleQueryControl". In this class, you have to override the method "IssueQuey" which will contains the logic for retrieving Data, it must be in a "System.Data.DataTable". And sets it to the PickerDialog's Results property. Don't forget to return the row count. Otherwise, no result are displayed.

In addition, override the method "GetEntity" that has a "System.Data.DataRow" parameter. This Row is a DataTable you have provided before. The goal is this method in to Strongly Typed your result with the "Microsoft.SharePoint.WebControls.PickerEntity" object. Which you can specify a Key, DisplayText. Then, the "IsResolved" property to true. This ensures that the provided entity is correct.

See blow the output of the Dialog (Step 2) that populates data corresponding to the entered input text:

When click on the OK button, the editor will receive the Entity value separated by the specified "EntitySeparator" if there is more than one Entity.

See the final result in the Picker Editor:

Hope it helps.

In my previous post, it explains how to display "Parts" regarding the NavigationManager used. Let me took your attention on the bindings:

MultiPartNavigationManager: {Binding Part.NavigationManager.ActiveParts} or SinglePartNavigationManager: {Binding Part.NavigationManager.ActivePart}

For everyone, it may a trouble when we want to activate Parts because the Binding is strongly linked with the NavigationManager used. It will be interesting to have only one way to "Bind ChildParts" even if there is one Part in the collection. In addition, it makes sense for WPF, because it allows to have a clean separation between Data and User Interface (UI). The sample below demonstrates this assumption:

<ItemsControl ItemsSource="{Binding Part.NavigationManager.ActiveParts}"> 
  <ItemsControl.ItemTemplate> 
   <DataTemplate> 
     <Awx:PartPane Part="{Binding}"/> 
   </DataTemplate> 
  </ItemsControl.ItemTemplate> 
</ItemsControl>

Microsoft Code Name “Acropolis” is a set of components and tools intended to make it easier for developers to build and manage modular, business focused, client applications for Microsoft Windows on the .NET Framework

You can download Acropolis CTP1.

Navigation is an important thing when we build an application. And, this feature is available with Acropolis as part of its kernel.

The goal of this post is to talk about what kind of Navigation Acropolis provide out of the box and what are its limitations.

Acropolis provides 2 kinds of NavigationManager class:

1. "SinglePartNavigationManager" that enables Single "Part" activation,
2. "MultiplePartNavigationManager" that enables Multiple "Part" activation

These classes inherits from "NavigationManager" class that implements "INavigationManager" interface.

In Acropolis, NavigationManager behavior maintains a collection of "NavigationItem" instances with a "NavigationItemState" i.e (Activated | Deactivated).

Basically, a "NavigationItem" is associated to a child part during the application execution. See the schema below 3 Parts are dropped as Children in the application.

How to specify the NavigationManager ?

<AcropolisApplication.NavigationManager>

<Afx:MultiPartNavigationManager />

</AcropolisApplication.NavigationManager>

 

How to view Part ?

In order to do that, we use a WPF Control "PartPane" provided by Acropolis that allows to display a PartView. See the XAML code below:

<Windows:PartPane Part="{Binding Part.NavigationManager.ActivePart}"/>

The XAML code above is the best way when SinglePartNavigationManager is used. In contrast to MultiPartNavigationManager, it is necessary to bind all parts to a list, in the XAML code below, an "ItemsControl" control is useed:

<ItemsControl ItemsSource="{Binding Part.NavigationManager.ActiveParts}">

     <ItemsControl.ItemTemplate>

         <DataTemplate>

             <Awx:PartPane Part="{Binding}"/>

         </DataTemplate>

     </ItemsControl.ItemTemplate>

</ItemsControl>

Depending which kind of NavigationManager you use, the behavior is below:

1. With SinglePartNavigationManager, only the last added part is activated (TaskPadPart3) and 2 first are deactivated (TaskPadPart1 and TaskPadPart2). See Figure 1. 
2. With MultiPartNavigationManager, all parts are activated (TaskPadPart1, TaskPadPart2 and TaskPadPart3). See Figure 2.

Figure 1.

Figure 2.

Limitations

Both SinglePartNavigationManager and MultiPartNavigationManager allow only "Single" Transition between Parts that are dropped into "AcropolisApplication.ChildParts". This means that these Parts live during the application execution even if there are deactivated. In order to activate a part, we must to call "NavigateTo" method available on NavigationManager and it requires to know which NavigationItem to be specified.

This case is suitable for RAD purpose but not in Software Industry where Part should be activated dynamically regarding UserContext, Business Scenario, and so on.

Conclusion

To sum up the navigation features that Acropolis provides by default, we can't have dynamic part activated by the navigation model, but it can be extented. Acropolis's Team has done an awesome job to provide a great open and extensible framework (hope it is not in final release :-)).

In the next post, we will focus on a NavigationManager extension based on UserAction Framework Navigation Model.

1. ORLinker Walkthrought
2. ORLinker Console Application

We are preparing a video about Team Collaboration workflow using ORLinker.