Geeks With Blogs
Silverlight RIA

The DataForm like the DataGrid control by default has the ability to auto generate fields based on the public properties of the object bound it.  This is controlled by the AutoGenerateFields property which is set to true by default.  I think the most common use for this feature is building demo apps and prototyping.  In those types of uses you can usually overlook the fact that there are a few properties with fields generated that you would never show a user of a business application.  In the rest of this blog post I will walk you through how you can add more control using a Silverlight 3 Behavior.

You can now also have more control over field generation by adding attributes to the class that you are binding to using the Editable and Display attributes.  Editable allows you to mark the property to be treated as read only or generate a one way binding.  Display as used below sets the AutoGenerateField property to false to ensure that the Age property doesn’t generate a UI Element.


You might have done similar things during the Silverlight 3 beta using the Bindable attribute which was replaced by using Display and Editable – see the change doc for more details. 

If you are using .NET RIA Services it helps by projecting attributes you place on the server side class metadata to the Silverlight client code generated.  When binding a class projected to the client by RIA services no extra work is required because these attributes are there.

These attributes help a lot and make it so there are even more places where the DataForm can be used.  One of the problems though is there are times where either you don’t want to mess with meta data, don’t have control over the class to add meta data, want a different set of fields included or excluded for a particular use.  In any of those cases probably the most common suggested work around is setting the AutoGenerateFields to false and specify a specific list of fields.  That can get real tedious real quick especially if you just wanted to hide a couple of fields.

The DataForm provides a useful event to help out here it’s called AutoGeneratingField.  This event is called as the DataForm is about to generate a field for a property.  In the event arguments you are passed the property name, the property type, a Field property and finally a Cancel flag.  The Field property is used if you want to provide a DataField back based on your own evaluation of the property name or type.  The Cancel flag though is what were most interested in for this blog post because it allows you to cancel generation of a field.  Using an event handler on that event you could accomplish the same thing we did with the attribute above as you can see in the following example.


While that’s helpful, I was really hoping for a way to package it up to be a little more reusable.  One way you could do that is inherit your own MyDataForm class from DataForm and override the OnAutoGenerateField method as you can see in the following example.


I’ve of course over simplified this a little but you get the point.  I basically have a property that can pass in the fields I want and if not in the list I cancel the generation.  I would probably also include an ExcludeFields property as well so you could stop one or two fields from generating.  Both can be useful in making the DataForm useful for more scenarios.  The problem with this approach is that you then have to always use the MyDataForm class to get the benefit.  In the next example we will look at how to use a Silverlight Behavior.

Behaviors and Triggers are a new feature that we gained with Silverlight 3 and are packaged as part of the blend SDK in the System.Windows.Interactivity assembly.  They are nice because they let you add capabilities to existing controls without having to inherit from the control. In the rest of this post we are going to build a behavior to allow us to filter the fields.  The first thing that needs to be done after we add a reference to the System.Windows.interactivity assembly is to create our class that inherits from Behavior as you see below.


You will notice that we specify DataForm as the control type for the behavior – this allows us to have a typed property AssociatedObject that is of type DataForm. 

What we want to do is hook into the AutoFieldGeneratingEvent like we did in the past examples.  Behaviors provide an OnAttached method that you can override and accomplish registering the event handler as you can see below.


In the event handler we basically use similar logic like we did in the prior example or more fancy if we want but the idea is for fields we want to not show we set the Cancel flag. 

Using the behavior is pretty easy the first thing you need to do is declare a namespace reference for the System.Windows.Interactivity and the library that contains the behavior class as you can see below.


Then on the DataForm control instance we can hook up our behavior by using the Interaction.Behaviors markup as you can see below.


Behaviors are cool because they can easily attach on to an existing control to add behavior that makes sense.  By attaching on they keep the core control from becoming bloated with features that only get used once and  a while.

If you think this might be useful to you, drop me an e-mail and I will shoot you over a copy of the code.

Posted on Tuesday, August 11, 2009 1:04 AM | Back to top

Comments on this post: Behavior to Control DataForm AutoGenerate

Comments are closed.
Comments have been closed on this topic.
Copyright © slria | Powered by: