Windows ME -> Longhorn?

A friend of mine raised the question "will Longhorn be the Windows ME of the XP Era?". This is an interesting perspective.

Tips and Tricks

Over the last week I have been reading a number of articles on .NET development, and was thinking on what I should do with the information I had read. What I wanted was to keep track of what I had learnt. My ideas were: 1: Write a Review of each article, 2: Add an entry to my blog.

I decided not to do 1 as I didn't want to do a full review of each article, I just wanted some notes to help me remember it and a link to refer back to it. I decided against 2 as well, as I don't really want to sort through both my blog entries to find information on that one article you want.

In the end I decided to create a new blog just for these tips and tricks. My plan is to use this as a repository for links to articles that I find useful, and a record of what was useful from the article.

If you are intereted the link is http://www.thoughtlabs.net/andrew/tipsandtricks

Examining the UPC Framework

Today I started looking into making changes to Microsoft's User Process Component Application Block. I am writing this blog entry so that I can remember what I have learnt...

The framework is as appears in the image here (from the UPC Application Block help).

As you can see, the UPC block centers around the idea of screen navigation. The coordinating class (in terms of the block) here is the Navigator. Developers provide the functionality for the Application (Your Application) the Controller (Your Controller) and the views (Your Views). The Navigator coordinates the transition between views.

One error on this diagram is the link between the Controller Base and the State. This is actually contained within the Navigator (i.e. the ControllerBase asks the Navigator for the State information). So the Navigator contains the state.

The navigator is loaded based on the information in the navigationGraph node in the Config file, or from the use of Open Tasks.

Goal: Remove the link from Your Views to Your Controllers.
Reason: Increase the reusability of Your Views, and the flexibility of Your Controllers.

Ideas:
Views have a specific purpose. Views can use and store information in State objects. A View which is accepting information from the user should store the supplied information in the State before propogating action requests.

Views can initiate actions (i.e. button clicks). Actions are received by a framework component and routed to the Controller, thereby avoiding the direct connection. The view has access to the Navigator (also not in the diagram), and so this can act as the Coordinator.

Concentrating on the Navigation Graph style for the moment:
Currently the graph has Nodes that have navigateTo links. These specify the destination view for a given action. For example:

<navigationgraph>
    <node view='Form1'>
        <navigateto navigatevalue='next' view='Form2'/>
    </node>

    <node view='Form2'>
        <navigateto navigatevalue='previous' view='Form1'>
        <navigateto navigatevalue='finish' view='Form3'/>
    </node>
</navigationgraph>

My thoughts so far suggest to replace navigateTo with a trigger node that contains one or more actions:

<navigationgraph>
    <node view='Form1'>
        <trigger value='next'>
            <navigateTo view='Form2' />
        </trigger>

    </node>
    <node view='Form2'>
        <trigger value='previous'>
            <navigateTo view='Form1'/>
        </trigger>

        <trigger value='finish'>
            <controllerAction name='updateDatabase' / >
            <navigateTo view='Form3' />
        </trigger>
    </node>

</navigationgraph>

The data for the 'updateDatabase' action would be taken from the tasks associated state information.

This allows the actions on the controller to be configured rather than hard coded.

User Process Components and State

I have had some more thoughts on user process components and thought I should try to put it into writing...

If we are to separate more completely the user interface from the processing, there still needs to be some way to share information between the user interface and the process, and visa versa. My current thoughts on this are leading me towards a more specific shared state. Let me explain.

In the current UPC (version 2), the state shared between the controller and the user interface uses a general key-value pair scheme. Both the user interface and the controller must know which keys contain which values, and which keys are manipulated by which user interface screen. This logic is not obvious from the types involved in the transaction, and so must be maintained in project documentation.

In order to further decouple the user interface from the processing, this state contract can be strengthened. Rather than using simple key value pairs, I believe that it will be better to introduce interfaces on the state information. Each of the user interface components (UIC) can then interact with one of these interfaces. The state passed into the UIC would conform to this interface, and the actions of the UIC would then guarantee that certain actions are performed upon the state passed in (view, add, update, etc.).

The User Process Component (UPC) framework would provide a base interface from which the other state interfaces would inherit. This interface would provide access to the key-value pair exposed by the state base class. More detailed interfaces would expose a more fine grain access, allowing access to specific data (possibly read only). Each interface would be designed to represent a single aspect of the state. In this way, multiple interfaces would be used on a single state item. For example you can have a IAddressInformation interface. This would be used to represent data that contains an address, such as a Customer, Order, etc. An Address form can then be created in the UICs, and can be used to manipulate address information for multiple UPC (for example Create Order, ChangeAddress, Register Customer, etc.) . As the actual processing is not within the UIC this will be very flexible.

This should be able to be implemented in the UPC version 2 framework. Something that I will have to look into soon.

Always remember to look on the bright side of life...

Blog Location

Have a look at this greate concept... Blog Locations.
My blog location is:



Have a look at http://www.csthota.com/blogmap/

XC#

Well I have tried to get XC# to work with Whidbey with no luck.

Installed ok, but when VS2005 was loaded it was unable to locate office.dll. The office.dll is used by the AddIn to interact with the command bars of Visual Studio. To fix this I modified the code so that it used the Whidbey style AddIn code to interact with the command bars, this does not require office.dll and so the AddIn now loads.

Now there is a problem with the XC# compiler. During compilation the compiler throws an exception as it is unable to load the System.Collections.Generic.Dictionary class. As I dont have the source code to this there is very little I can do...

At the moment I want to play around with Whidbey a little more, so I will delay a look at this until after I have finished playing with this.

Aspect Oriented .NET

On another of my projects I am looking at ways to help automate commonly repeated tasks. For example. In this project, all exceptions within the service layer are managed and wrapped in a custom exception. The Exception Management application block is used to publish the exceptions details. Each of the exceptions has an associated Publishable Exception, which contains the exception to be thrown beyond the service layer. This ensures that only appropriate exceptions are made public.

In order to implement this all public methods in the service layer must catch all unhandled exceptions and then throw the associated Publishable Exception. For example the code is something like this:

public void ServiceLayerMethod(Parameters p)
{
try
{
...
}
catch(Exception exc)
{
Manager.RaiseFilteredException(exc);
}
}

While this is not much code it is annoying to type, and a bigger problem if missed.

Getting this out of the code and into some form of aspect, or even attribute, has been a goal of mine for a while. This can be achieved by using ContextBound objects, but this forces the developer to inherit from this class and is not as flexible as I would like. Today I have spend some time looking into some of the other Aspect Oriented extensions for .NET. This has lead me to XC# from ResolveCorp. I have only just download the VS2005 version and will investigate it over the next few days.

Has anyone tried using this? The documentation on the site is very thin... but it does appear that I should be able to implement this as an aspect. If this is the case the plan is to create a ExceptionManaged attribute that can be applied at a class or method level. At a class level, all non-private methods will be wrapped with the exception management code.

If you have had any experience with XC# that you think will help please let me know... if not I will post up my progress as I go.

UIP Application Block

I have started reading the details about the application block (User Interface Process Application Block - Version 2). The block aims to allow you to more easily implement MVC applications where the transitions between views is flexible. The block states that it wants to make it easier to "Add new pages", etc.

The block implements much of this very well. The views are, however, coupled to the controller. On page 60 of the PDF that comes with the block it indicates "to add navigations to your view call the methods defined within your controller." This has several negative side effects.

Firstly, it is now difficult to add new views into the application. If additional steps are added to a user interface process, this requires changes to the existing views, and controller, and the addition of the new view.

Secondly, you cannot use a single view for multiple tasks. In some cases it may be possible for a single view to participate in multiple tasks. If the controller is directly called from the view this is not easy to implement.

Ideally we should be able to decouple the view from the controller. This in itself will be a complex addition as there is some coupling required between these entities. The controller is currently decoupled from the view. However, operations of the controller will require information from the view.

How this can be decoupled must be considered carefully.