All posts by Julian Dominguez

ICommand for Silverlight 2.0 RTW Updated Sample

Some time ago, we blogged about how to implement the ICommand feature that is available in WPF but missing in Silverlight.

The sample included in that post was using Silverlight 2 beta 2, so I updated the code now to target Silverlight 2 RTW. The main difference is that the old code included the ICommand interface which is now available directly in the Silverlight 2 bits (although there is no class implementing it, nor the input controls know how to bind to it).

Read the full blog post here:

Downlad the updated sample code here:

Presentation Model with DataTemplates in CompositeWPF (Prism) Sample

Sample on how to use the Presentation Model pattern in WPF with the help of Prism and automatically injected DataTemplates.

Read More

Composite Application Guidance (Prism) vNext envisioning

If you want to know what has been keeping us busy for Prism vNext, read this detailed post from David Hill.

An excerpt from his post:

Prism 2.0 will focus on two things:

  • Extending the guidance delivered in Prism 1.0 for building composite WPF applications to also support composite Silverlight applications.
  • Adding guidance for building ‘multi-headed’ applications – applications that can deliver both a desktop and an in-browser experience.

David Hill has been working and contributing with p&p in many projects, and has recently become the new architect at p&p. So be sure to add David to your RSS, because there’s probably lots more to come related to the guidance that p&p is providing not only with Prism vNext, but with other assets like EntLib.

ICommand for Silverlight with Attached Behaviors

How to use the ICommand concept from WPF in Silverlight by using attached behaviors.

Read More

Composite Application Guidance for WPF goes RC!

The Composite Application Guidance for WPF (formerly known as Prism) was finally released as Release Candidate in the codeplex site. The final release will be published on MSDN soon.

If you haven’t been following the weekly drops, here’s a quick summary of the contents, as this guidance comes in many forms, such as:


  • Composite Application Library

      This class library comes in form of source code. You can build it, reference it, extend it, modify it, extract pieces of it, or do whatever you feel like with it because it’s under Ms-PL (all the source code in the release, including CAL, the Reference Implementation and QuickStarts, are under this license).

    The Composite Application Library is designed to address requests from architects and developers who create WPF client applications and need to accomplish the following:

    • Build clients composed of independent, yet cooperating, modules.
    • Separate the concerns of module builders from the concerns of the shell developer; by doing this, business units can concentrate on developing domain-specific modules instead of the WPF architecture.
    • Use an architectural framework to produce a consistent and high quality integrated application.
  • Documentation

      Totally wicked documentation! It’s useful for both architects and developers. This is not the typical last minute documentation after a project ends, but an awesome first class citizen of the project… you should definitely check it out.
      Composite Application Guidance for WPF documentation
  • Reference Implementation

    [The RI] is an application that illustrates the baseline architecture. Within the application, you will see solutions for common, and recurrent, challenges that developers face when creating composite WPF applications.

    The reference implementation is not a real-world application; however, it is based on real-world challenges customers are facing. When you look at this application, do not look at it as a reference point for building a stock trader application… instead, look at is as a reference for building a composite application.

    Stock Trader Reference Implementation

  • QuickStart sample applications

    The QuickStarts […] are brief, easy-to-understand illustrations of key software factory activities. QuickStarts are an ideal starting point if you want to gain an understanding of a key concept and you are comfortable learning new techniques by examining source code. The Composite Application Guidance includes the following QuickStarts:

    • Dynamic Modularity
    • UI Composition
    • Commanding
    • Event Aggregation

I guess all that is left is for you to download it and try it out, as it is very easy to consume and find out if it’s good for you or your team.

Remember there is also a community and active forums to help you building you composite applications with the library. So if you have any issues, doubts, comments, feedback, please stop by the codeplex discussion list for the project.

Happy coding!

Download Composite Application Guidance for WPF

UPDATE: Link to final release landing page on MSDN

Technorati Profile

First approach to Presentation Model with DataTemplates

In my previous post I talked a little of a new way that WPF allows us to create (and inject) a view by using DataTemplates (or ControlTemplates). I talked about how the use of templates combined with the Presentation Model pattern can help you build fully testable applications.

I was contrasting the benefits of using Presentation Model against the Passive View’s flavor of the MVP pattern when using it in the WPF world. I want to clarify that the Stock Trader reference implementation that’s being shown with the Prism project is not using Passive View (it was in the very first drop, but not anymore)… it has a mix of MVP with Supervising Controller (as of today).

The spike made by the Prism team that I was talking about was released here (get the zip, and the spike is under the PublishedSpikes folder).

The spike was based on the existing UIComposition QuickStart, so not all the code there is related to DataTemplates (as I said, it is just a spike and not production code, but we thought it would be interesting to put it out there). You are very welcomed to check it out. I won’t use the same example as the spike in this post, as I want to focus only on the templating part and leave the rest out.

One very neat thing about using templates, is whenever you add a model into the Visual Tree, WPF will automatically inject the view (template), assign the model as it’s DataContext and render it on screen. How? Well, let’s see an example.

You first need to create the DataTemplate you want to use:

<DataTemplate DataType=”{x:Type models:OrderModel}”>
  <StackPanel>
  
<Grid>
    

     <Label Grid.Row=”0″ Grid.Column=”0″>Customer Name</Label>
    
<TextBox Grid.Row=”0″ Grid.Column=”1″ Text=”{Binding CustomerName}” />
  
</Grid>
  
<TabControl ItemsSource=”{Binding LineModels}” />
   
<Button Command=”{Binding SubmitOrder}”>Submit</Button>
</StackPanel>
</DataTemplate>

You could place this portion of XAML in the App.xaml as a resource, but if you do this for every view in one centralized place, that file can get very big, hard to read, hard to manage, and what is worst, all devs or designers will try to edit that file constantly at the same time. Furthermore, if you’re developing different modules (like what you could do with Prism), you will not be able to deploy the modules independently.

Best option: create separate ResourceDictionary files where you can put one or a few tamplates grouped logically. Later on, you can merge these resource dictionaries by using MergedDictionaries in the App.xaml as explained here.

“Ok now, but if I’m using Prism, I cannot accomplish decoupled modules if now my application class has to know about all the resource files in all my modules!”. Fortunately, all that can be done in XAML can be done programatically, so instead of using MergedDictionaries on App.xaml, you could have your Module initialization logic to merge the isolated dictionaries into the application wide ResourceDictionary. In the spike published by the Prism team, this is done with the following code:

ResourceDictionary dictionary = new ResourceDictionary();
dictionary.Source = new Uri(“pack://application:,,,/OrdersModule;Component/OrdersRD.xaml”);
Application.Current.Resources.MergedDictionaries.Add(dictionary);

Now that the initialization has being done, all you need to do is “show” this model. For example:

Window mainWindow = new Window();
mainWindow.Content = new OrderModel();
mainWindow.Show();

On the next posts I’ll try to gather a downloadable sample, and show how to use commands to work in these scenarios. Also I’ll show how to use two-way bindings to communicate actions from the view to the model when commands are not enough.

kick it on DotNetKicks.com

Using the Presentation Model in WPF

In this post (of what may become a series of posts if I find some interest from the community) I compare 2 different approaches for separating view code from business logic in order to reduce the untested surface area while doing TDD.

The Passive View pattern

I have been using the Model View Presenter (MVP) pattern (or more specifically the Passive View pattern) for a long time now, both in the Winforms and WebForms worlds.

The main reasons for this? Testability and separation of concerns. As a TDD adopter, I want to be able to unit test as much logic as I can.

Passive View works fairly well, allowing me to keep the view (usually in the form of a user control) somewhat thin in order to satisfy myself without testing it (you know how difficult/impossible it becomes to unit test a UI screen).

In practice, applications written using Passive View end up having lots of boiler plate code for the communication between the view and the presenter. It also makes it very prone to start putting more knowledge on the view than what I’d like, not only for laziness in trying to avoid forwarding messages (that require very simple processing) to the presenter, but also in some transformations needed to keep the presenter agnostic of the specifics of the UI implementation.

WPF templates to the rescue!

In the Prism project we’ve using the Passive View approach also, as a logical step to adopt WPF when you come from winforms / webforms.

In the last time, though, I have been becoming very fond of another approach that is very easy to implement now using the WPF templating and databinding capabilities that weren’t available before: the Presentation Model pattern. This has been also called Model-View-ViewModel by John Gossman / Dan Crevier (if you haven’t read their blog posts on this topic, you MUST read them).

What I would like to add/highlight in this approach is that in WPF you can enforce keeping your view extremely thin by avoiding the use of UserControls or UI-coupled controls. Instead, you can create DataTemplates of your Presentation Model classes, and those model instances are the objects you’ll add to your Window. When your model gets laid out in the visual tree, WPF will automatically pick up the correct template for that model, and render the model appropriately.

This approach relies extremely on data binding, because there is no code behind at all on the views, just XAML markup.

Most of the times I end up deriving my presentation models from DependencyObject to benefit a lot from dependency properties.

In some cases where UI complexity dictates it, the model may derive from Control instead. "What?!? a model deriving from a Control?". That was my first thought when I came to that possibility, but it was highly biased from my Winforms past. Controls (don’t mistake with UserControls) in WPF are totally lookless and do not rely on the UI, so they can be tested in isolation. To render the appropriate view you’ll need to create a default ControlTemplate (compared to a DataTemplate for plain objects or DependencyObjects). One big benefit about using Controls is that you can maintain a WPF logical tree of presentation models (there are some benefits about this which I won’t cover in this post).

I’m planning on providing you with some code samples in the future, but in the meantime guess what: The latest Prism code drop will be including a spike we did using this approach. You should check it out and see how it feels. Notice that this is just a spike and we are only releasing it in order to get feedback from you guys, and see what is the interest on seeing more of it.

New Prism drop: Refactoring time!

A new drop of Prism is out there. If you haven’t yet taken a look at Prism, you should definitively do it.

This last iteration’s goal was mainly about refactoring and making lots of changes that as the framework evolved we were not very comfortable with. We had reached a point where we had so many PostIts in our refactoring wall that we were saving for later, that we decided to spend a whole iteration on them.

wall_refactoring

You can read the high-level changelog on the Codeplex release page for the drop and Ezequiel’s post, so I won’t repeat them, but I’ll comment on some of them.

  • IMetadataInfo (and IMetadataInfoProvider) was removed from the Prism framework.

Previously, the Prism framework was playing a part in connecting some header metadata for a view to the region it was placed in (in some sort similar to what SmartPartInfo was in CAB). This was not flexible enough in the WPF world, where you could use your creativity and designer skills to come with a super cool UI (or at least not the ol’ basic gray tab control).

Furthermore, there is no real reason to provide framework help on this, when it’s easy enough to just use WPF bindings to provide the metadata or title text for the view that gets placed into the region. Don’t worry, is not that you get nothing now when you were at least getting some help before: you will still receive guidance (for now in form of a Reference Implementation and QuickStarts).

  • We are now using generic commands (DelegateCommands in Prism) in a more consistent way than before.

You’ll also probably notice a commands proxy class that does nothing else than redirect to a set of static commands. If you look closer at the code usages, you’ll notice that this class is inherited in the unit test projects for mocking purposes, to avoid using the static instances of the commands that would mess up the independence of the tests.

There are literally several dozens of changes and fixes, so please get the latest drop and give us your feedback on it, as we are using your feedback immensely.

Web Client Software Factory – February 2008 is live

Good news people: WCSF 2.0 was finally shipped.

There were a lots of changes since the June 2007 release (WCSF 1.1). Many of you may have already downloaded the bundles that were released in October through December.

The big change since the October 2007 releases (apart from having all the content that was shipped as separate bundles in a single deliverable) is that this release targets Visual Studio 2008 and .NET Framework 3.5 natively. There are also some changes that enhance the performance of the Composite Web Application Block, and some other minor changes and bug fixes.

There are already some great posts about this release that contain detailed information of this new release, so instead of writing it myself, I’d better link you to them:

Go to the Web Client Software Factory website and download the installer now!

JavaScript frameworks comparison table

Some weeks ago we did a quick research about the different JavaScript frameworks/libraries out there. We didn’t take into account every framework on the web, and chose especially those that can integrate easily with ASP.NET WebForms.

I’d thought I’d share the results with the community in the form of a comparison table. You can use the results as you wish, but I warn you this is by no means exhaustive.

List of frameworks/libraries we considered

comparison_crop

Download the full table as PDF

Categories

  • Visual components library: Availability of widgets in official releases and/or add-ons
  • ASP.NET integration: Ability to control its features from the server
  • Easy to brand: How easily can you perform custom branding of the UI (styles and layout personalization, this is a requirement in a S+S application)
  • Ease of use: Time taken to recode a demo
  • Ease of use with Visual Studio: Time taken to setup a website for using the framework
  • Documentation: Presence of documentation / demos with code / guidance from its official site
  • Visual enhancements level: Quantity of JavaScript code needed to add simple effects (such as fade or resize) to a panel
  • Web services support: Support for JSON serialization
  • Browser history integration: Support functions for handling browser history (browser does not track async postbacks without JS code to handle this)
  • Client side event handling: Support for attaching to events on runtime

I hope you find this information useful.