Monday, June 29, 2009

Adventures while building a Silverlight Enterprise application part #14

As some of you may remember from the very first episodes of this series, in our application we use modules to separate functionality. This allows for a scalable solution on many fronts. Recently however I was asked by some of the functional designers if it was possible to use the modules in multiple ways.
Now this always was the plan, but some of the requirements were missed in the earlier stages of our project. We didn't anticipate the fact that, not only would our modules have a different look, based on where they would be used, also they would have to have some features change, based on the fact that they were used differently.
Here is what we have identified we need:
  • Normal use: this is basically how we have our modules in our applications. They should display there titles on the top, provide sizing capabilities for either two or three formats (title bar only, normal view and extended view for datagrid modules), provide a save button (and a new button for our datagrid) and some other functionality.
  • Wizard use: we want to stack some modules on top of each other in different steps of wizards we provide for our users. This means the title bar should be gone, the new and save buttons are not there, modules can't size and there should be a title on the left with a description for each module.
  • Popup use: we want some modules to be able to pop up and be modal to all other parts of the UI. The exact requirements are to be determined.
  • Separate use: we want to be able to use some modules as a standalone peace of kit. Again we're not completely sure as to what the requirements will be.
I pondered about this for a bit and then said, "sure we can do this, just give me a day". Here is what I came up with. I decided that each module should not provide any of the functionality that has to change between uses. These functionalities should be provided by a container. I could then build a container for each use of a module. This allows me to not only provide XAML code in the container (which, as you all know from a previous post is not possible in base classes for user controls). It would also give me a single point to change these shared functionalities, which took away another conceirn about not being able to implement changes to the general functionality of a module without touching each module.

I went ahead and put this in our application and I was pleased by the fact that it was so easy to do this in Silverlight. I simply have a usercontrol with the functionality and XAML required and all I needed to embed a module was a ContentPresentor and to have some interface (IModule) to provide access to some of the functionality inside the module (like save and new).

I would love to show you some code, but I can't as this is part of my companies software. Still I hope this inspires anyone that needs to have a single point to put code, but still needs to be able to place XAML as part of that, to consider using a container type of solution with the ContentPresentor. If you have any questions, comments or other responses, please wait for the beep...

Beep! :-)

No comments:

Post a Comment