Search

Here at NeuroSpeech, we figured out the problem with forms based business applications that frustrates developers and change management is not only time consuming but its quite boring job to do.

Although WPF/Silverlight does offer very customizable UI designing platform but when we go on the field to develop ling of business applications, we realize that initial development hardly takes any time but maintenance is very difficult.

There is lot of buzz about LOB Business Form Layout for new platforms WPF & Silverlight, both capable of displaying rich content and extend functionalities of existing components so better then ever before.

XAML is better then earlier Rapid Form designers where you need to drag and drop within an IDE and the layout management becomes so complicated because no IDE is perfect. I remember upgrading from Visual Studio 2005 to 2008 and now 2010, most of our ASP.NET and WinForm projects would require lot of effort to work seamlessly in newer versions. The worst of all is, modifying layout without IDE becomes way to difficult.

While off reading random blog posts on the tubes, I stumbled upon a post that describes a 101-level scenario of using lookup data in the DataGrid and DataForm with RIA Services.  The author was struggling to find a solution for the problem and was clearly frustrated.

In the previous part of this article I introduced a custom Form control I made for some real world projects. I've briefly explained the reasons why I choose to not use the Silverlight Toolkit's DataForm, just before to show how to build this control, and I've also detailed what I like of the DataForm and what I should retain in my Form control.  One of this features is the validation of the input and it is what I'm about to describe in the second part.

Download Source Code

The databinding in Silverlight directly supports the validation through a couple of attributes, that let the developer specify if the markup extension has to notify validation exceptions to the control binded to a property so it can show the errors to the user.

Working with DataForm I found difficult to use it in many scenarios due to its design. So I've created a control where I do not generate fields but I handle automatic validation and cancel/commit commands enabling also the usage of the control in mvvm scenarios. This is a good starting point to understand about Validation, BindingExpressions and traversing the visual tree.

-----

The first time I've met the DataForm control - it was some days after its beta release in the Silverlight Toolkit - I was really astounded from its power. It is capable of many wonders: it generates fields detecting the properties of the binded item, it automatically validates the input values using a bunch of attributes in a way similar to ASP.NET Dynamic Data, it manages the workflow passing through Edit, ReadOnly and Insert state, and these are only a small subset of the features it exposes.

Read part 2 of this article series called: A simplified DataForm replacement - Part 2 Adding validation support

Building robust Silverlight applications that edit and validate data got a whole lot easier with the introduction of the DataForm control in Silverlight 3. The DataForm control contains several features to help create forms that allow adding, editing, deleting and navigating through sets of data. The greatest benefits of the DataForm are its flexibility and customization options.

In this blog post John Papa talks about getting the debugger to ignore validation exceptions.

I recently wrote an article that demonstrates how to use the DataForm and validate data entry in Silverlight using the DataAnnotations. One of the pet peeves I have with the validation is that it throws in exception in the setter of your public property. Putting my disagreements with that aside for a second, it causes a major inconvenience when debugging the application. For example, when running the application that uses the DataAnnotations and one of the conditions is violated, the debugger will catch the validation exception and break into the code. The desired behavior is that the debugger will not break into the code since I really just want to see the validation information on screen.

When DeleteItem is called on DataForm (via the built-in toolbar or via your own methods), it deletes the current item.  After all, that’s what you told it to do!  The problem is that the delete is fast and there is no easy “undo” method. 

Luckily, DataForm provides a method interceptor for us: DeletingItem.