CodeMetropolis

Unleash the power of VisualStateManager with custom states

Marco De Sanctis — Sun, 29 Jun 2008 22:12:03 GMT

Property triggers are the WPF feature I miss the most in Silverlight 2: I really liked writing behaviors in declarative style with XAML and Styles and it was somehow frustrating being forced to use C# code and event handling to achieve similar results in Silverlight.

Although it's not here for exactly the same puropose, VisualStateManager is a great improvement to fill the gap thanks to:

Blend visual support
automatic state transition animation

Those two features, combined with the opportunity to inject custom states at your own will, make VisualStateManager so poweful that you're going to miss it once back to WPF, at least until it won't be supported for smart clients too.

Let's suppose I want to animate a textbox to change its background color when mouse pointer overs it. If I was in WPF I would have attached a trigger to the IsMouseOver property, in Silverlight we got no triggers, but we have Blend and VisualStateManager.

So what I do is putting a TextBox in my UserControl and ask Blend to customize its template:

As we can see, we got no states for the standard TextBox so VisualStateManager seems to be unuseful at first: should we once againf rely on procedural code to achieve our goal? Not at all (or, more exactly, almost not at all). Even though standard TextBox has no built-in states (it doesn't specify any in its attributes nor it invokes any state transition, as, for example, Button does) we can easily add our own simply editing the generated style XAML markup.

What we need is a custom StateGroup, called MouseStates, and a couple of states, Normal and MouseOver, so what we do is opening Visual Studio to have intellisense while typing, adding a reference to System.Windows namespace and writing the following lines of code:

Visual Studio complains about using VisualStateManager.VisualStateGroups attached property; however, don't care about it, everything will compile without errors. Ok, now back in blend to continue editing the control template:

As you can notice, Blend recognizes the 2 newly added states and suddenly adds them to the States panel. Now, we can animate the TextBox background as we would usually do:

Now we only need one last step: adding some code to invoke state transitions when the mouse pointer overs or moves away from the TextBox. So, back in Visual Studio, let's add a couple of event handlers:

Now, if you build and run the project, you'll notice how the TextBox gracefully changes its background color from white to shaded red. However, our textbox won't work in another UserControl unless we don't add the same event handling code to it. It would be preferrable to build a custom StateTextBox and internally hiding all that logic. Doing it is extremely easy, as it consists only on creating a class which inherits form Textbox and writing code similar to the previous one:

Notice the two attributes I added to the class declaration to describe the control's state machine structure; Blend is supposed to read them to show controls states when editing its template. Unfortunately, (as I wrote some days ago) Blend June CTP current version has template editing capabilities only for controls which belong to System.Windows.dll. It means that even if we use StateTextBox, we'll still need to manually do all the stuff. However, it still has the advantage to leave the page code behind free from any textbox state transition code.

As usual, source code is available here.

Technorati Tags: Silverlight 2 Beta 2,VisualStateManager

Blend 2.5 June CTP and custom controls templating

Marco De Sanctis — Wed, 25 Jun 2008 08:18:44 GMT

I've been recently doing some experiments on Silverlight and the new Blend June CTP. I'm amazed by the design support to custom template editing it provides, although I couldn't get it work with my own custom controls.

I though I was mistaking something, perhaps forgetting some attribute or whatever else; after 2-3 days of tests, I finally gave up...

Today I've found this post explaning that

Currently Blend doesn't support copy ControlTemplate that are not define in System.Windows.dll. But you should be able to create an empty template and edit it.

Ok... at least it wasn't a fault of mine..

Technorati Tags: Silverlight 2 Beta 2,Blend

TransactionScope timeout

Marco De Sanctis — Fri, 13 Jun 2008 22:01:12 GMT

TransactionScope constructor has an overload that lets you specify a transaction timeout:

The example above sets up a 1 hour timeout on the new transaction. I was using a similar approach to execute an Oracle stored procedure which was doing some batch processing that took about 30 mins. to complete. Anyway, I could se the transaction being rolled back after about 10 minutes, even though the OracleCommand itself had a proper timeout and no exception was raised by the underlying stored procedure.

Pretty strange, isn't it?

After some research, I've discovered that the TransactionManager class, which ultimately manages the transactions lifespan, has a readonly MaximumTimeout property, that can be set only at machine.config level and has a default value of 10 minute:

This is the maximum time limit your transaction can last, regardless of what you specify on the aforementioned constructor. In my case, I decided to move it to one hour limit.

Hopes this saves you a little time ;-)

Technorati Tags: Distributed transactions,TransactionScope,Timeout

Custom controls and default template in Silverlight 2 Beta 2

Marco De Sanctis — Wed, 11 Jun 2008 09:37:20 GMT

As Corrado Cavalli pointed out in his blog (sorry, it's in Italian), in Beta 1 custom controls didn't inherit their parent's default template; that means they didn't have any visual representation unless we explicitely provide a default template for them. It was a bit annoying, especially when we only needed to add some logic to standard controls, like creating a CustomTextBox that accepts only numbers, for example.

I was happy to realize that in Beta2 this limitation has gone: when building custom controls, we no longer have to create a default template for it, as it's inherited from its base class (if none is provided). Starting from Corrado's example, let's create a CustomButton class

Now, if we place it in a Silverlight user control:

we obtain exactly what we expected:

Fair enough!

Technorati Tags: Silverlight 2 Beta 2,Custom controls,Styles

Silverlight 2 Beta 2 Documentation Available

Marco De Sanctis — Fri, 06 Jun 2008 08:17:57 GMT

If you are excited about Silverlight 2 as I am, and you can't wait for its upcoming beta realease, you'll surely enjoy this: Silverlight 2 Beta 2 SDK Documentation is available.

Let's hope it anticipates the SDK public download only for a few hours.

Technorati Tags: Silverlight 2 Beta 2

When Lazy Loading associations is useful

Marco De Sanctis — Thu, 22 May 2008 10:28:42 GMT

I was going to reply to a feedback to my last post, but from how much I was writing I realized it could deserve a post on its own.

When we decide to adopt the Domain Model pattern to represent data, we're going to deal with complex object graphs: it means that instead of SomeRelatedEntityId properties, we will have concrete references to related entities, a property of SomeRelatedEntity type in this case

Obviously, when you start a business transaction and you know from the beginning that the property X will be accessed, it could be (not always, read below!) a wise choice to eager fetch it to avoid too many DB round trips. However, I consider LazyLoad very useful in at least two practical cases:

n-level Master-Details: for example, a form with a header to edit the master entity, a grid below for its details and a button for each row which opens an AJAX modal popup to edit the detail's details. Without LazyLoad you should execute a huge query on the beginning (or many smaller ones) to fetch everything, and perhaps the user only wants to modify a Master's field. Oh... and what if the 2nd level details have many-to-one associations towards other entities? How big should our join be?
There are good chances that the related entity is still in the identity map: let's think about a list of entities with many-to-one association towards the same entity, for example a list of bills of the same customer. Without lazy load, you would fetch the same data many times, with lazy load and identity map, you will have no joins, only one query towards the Customers table, then the same entity will be used for every Bill.

Technorati Tags: LINQ to Sql,Architecture,Lazy Load,Domain Model

Linq To Sql in real word Web applications

Marco De Sanctis — Tue, 20 May 2008 21:34:23 GMT

As my Italian friends probably know, I'm a huge NHibernate fan, as I decided to permanently adopt it in many desktop and web apps I've built or designed during the last 2-3 years; dealing with Session life cycle management in ASP.NET apps is pretty simple if you use well known patterns like

Session per Request
more rarely, Session per Conversation

In other words, you have a session alive and kickin' for the whole business transaction your WebForm is accomplishing and, being the NHibernate Session a Unit of Work implementation, this is absolutely faithful to that pattern definition.

For some reasons, using a similar approach with Linq To Sql's DataContext is not as easy. Let's take a look.

Dealing with detached objects

Let's start saying that associations in L2S are lazy fetched by default, so you need to have a context alive while navigating the entity graph if you don't want ObjectDisposedExceptions to be raised:

When adopting a Session per Request pattern, you must frequently detach/reattach the entity versus the current request's DataContext; however, attaching a detached entity in Linq To Sql is not as easy as it's supposed to be, as it isn't a supported scenario. I blogged in Italian a while ago about some strange reattaching behaviors I experienced in Beta2; RTM throws an exception if you try to reattach a persistent entity with associations not yet initialized, at least that's a more consistent behavior, although it doesn't help.

In other words, unless you don't want to deal with workarounds, you can't use Session per Request pattern with Linq To Sql.

Moving towards Session DataContext per Conversation

That brings us to the decision of having the same DataContext alive for the whole business transaction. I'm fine with that, although the architecture becomes a bit more complicated because its life should span several postbacks. After chatting a while with my friend Alk, I realized that ASP.NET's Cache is an awesome storage mechanism for DataContexts because:

In a perfect world, every business transaction should be explicitely closed. In real world, however, users tend to close their browsers without notice. If we use sliding expiration, the ASP.NET's caching infrastructure takes care itself on getting rid of every pending DataContext that hasn't properly been disposed.
Cache's sliding expiration is automatically renewed on every access.
Cache provides a callback mechanism, so we can execute custom code when a DataContext has expired.
We can configure Cache to not remove DataContexts when the system is in need of memory.

Instead of directly storing the DataContext, it's a better choice to wrap it in a generic UnitOfWork instance; this allows us to inject a bit of additional (and useful) logic:

The Items property, for example, is a string/object dictionary (an idea borrowed from NHibernate.Burrow) used to store custom transaction items that need to last till the transaction ends; I've also provided a Disposing event if the user wants to execute some custom code when a UnitOfWork is closed.

A UnitOfWorkContainer singleton object keeps track of all active UnitOfWorks and provides methods to start, rollback or commit (business) transactions:

Thanks to that, building a new UnitOfWork and storing it in the cache repository is only a matter of calling the BeginTransaction<T> (T is the Linq to Sql context's concrete type) of the UnitOfWorkContainer singleton class:

That method returns an ID which can be easily stored (f.e. using Viewstate) and will be used to retrieve the current UoW during the future postbacks. Now that a UoW has been created and stored into the container, we can retrieve it very easily

and we can use it to interact with the underlying Linq DataContext or with the Items storage as well; for example, the Page_Load method in my example contains the following code:

Thanks to this code, in every postback we have a reference to the person currently edited through the entity filed, we can freely navigate its object graph with the DataContext automatically querying the underlying database if it needs to lazily initialize any property, and tracking every change we make to any entity, being it the current Person instance or any associated one. Not bad, isn't it?

After some postbacks, here it comes the end of the conversation, in which the user is asked to say "Ok" and persist the changes, or say "No" and cancel everything; this ends the business transaction and invalidates the UnitOfWork:

Few details on what happens behind the curtain

The UnitOfWorkContainer class acts as a repository, providing methods to manage a UoW's lifetime and retrieve it given its Id. Once the user decides to begin a new business transaction, a new UoW is created and added to ASP.NET Cache:

Two details to notice here:

The cache item is marked as NotRemovable, so it won't be cleared in case of memory shortage; it will disappear only after a 10 minutes sliding timeout or if explicitely removed.
I've subscribed a CacheItemRemovedCallback to dispose the UoW once it has been removed from the cache (and, therefore, not reachable anymore from the client code)

Obviously this is only a very simple example, something very similar to what I used to do with NHibernate. For those who are interested on it as a starting point for their own apps, source code is available here.

Technorati Tags: LINQ to Sql,ASP.NET,Session per Conversation

Create a WPF skinnable ImageUploader control

Marco De Sanctis — Wed, 14 May 2008 23:12:44 GMT

In a previous post, I showed how you can directly bind a Binary LINQ type to a WPF Image control implementing an ad-hoc type converter, not so much useful unless you don't have your images already stored on your database. What we need is something that is capable to achieve a two way binding, both displaying images and allowing users to upload their own; what about a brand new, completely skinnable, WPF custom control? So, let's create a new WPF project and add a new CustomControl called ImageUploader and take care of its logic first. As I wrote elsewhere, it's a good practice to design control's behavior (and implement it) without references to any UI element.

First of all, we need a property where to store an ImageSource object; we want it to be two-way bindable, so we are going to build a dependency property instead of a plain CLR one with appropriate FrameworkPropertyMetadataOptions:

Next, we need a couple of commands:

a Clear command (we want the user being able to remove the current image)
a Browse command to upload a new picture

If you've read some posts of mine, lately, you should perfectly know how to create custom commands and bind them to handlers

The ClearImageCommand handler is pretty straightforward:

Same for the BrowseCommand handler, although it deserves one little note: we could obviously use the BitmapImage constructor with a URI as argument to directly reference the file; however this approach leaves the file locked for the whole BitampImage lifetime (which unfortunately ends only when GC wants to). Therefore what we do is manually handling its loading, setting the CacheOption property to load the entire image data during its init stage and caching it in a MemoryStream:

Now that our control's logic is completely defined (and, again, without references to any UI element), we can move to creating a default layout on the generic.xaml file; a very simple one could be the following

that is not so bad if we add a bit of animation...

Anyway, doing something fancier is only a matter of Blend skills (and mine are awful).

One last note: the BinaryToImageConverter I showed you here is still one-way only. To get it work in both directions, we must implement the ConvertBack method:

Here's the complete source code, obviously released under the "Works on my machine" license

Enjoy!

Technorati tags: WPF, WPF Binding, WPF Custom Controls

Cool, professional (and free!) WPF controls

Marco De Sanctis — Mon, 12 May 2008 08:37:03 GMT

Today I saw a post of a friend of mine about WPF lacking some of the controls we used to have in Windows Forms (who said DateTimePicker? or was it DataGrid?). Indeed, there are many Open Source project to fill the gap, like AvalonControlsLibrary or WPF Toolbelt, but beside that, Xceed has an excellent DataGrid (although not so straightforward to use) which has a free express edition that can be used even in commercial apps.

The cool thing is that the package includes a bunch of other useful controls, like a DateTimePicker, a MaskedEditTextbox, and so on, that can be obviously used on their own. Moreover, everything is well documented and with many samples.

Uh... I was almost forgetting, I'm not related in any way to Xceed Software, it's simply what I think could be a good advice.

Technorati Tags: WPF Controls,DataGrid,DateTimePicker,Xceed

Beware the XamlParseException...

Marco De Sanctis — Mon, 12 May 2008 06:43:49 GMT

...it doesn't necessarily mean that there's something wrong with your Xaml: it's thrown for any error during the constructor execution, even though it's caused by a C# line:

Technorati tags: WPF