Geeks With Blogs
Deep Ena
In part 1 of this article I talked about how Object Container Data Source (OCDS) can be modified in WCSF to make two-way binding possible with complex objects. In this part I am going to talk about different issues you might run into while using two-way data binding with FormView/GridView controls in a complex page layout and at the end of the post some really cool benefits of using OCDS.
 
To get two-way data binding work with complex page layouts, the web page has to be broken down in the logical combination of controls that can be mapped to a Domain Model. This can become even trickier when the controls on the layout do not have a logical grouping. FormView/GridView controls do not allow access to the controls added to them at compile time by design. This would essentially force the use of FindControl when we hit the edge scenarios of two-way binding. This code will become ugly really fast because of the hard coding, which we are trying to avoid in the first place.
 
 Making the combinations of FormView/GridView to make the page two-way bindable, the following are the gotchas/limitations while implementing two-way binding:
 
Scenario 1: Does UpdatePanel/FormView combination have limitations? When trying to use an update panel with a FormView, two-way binding will only work when FormView is added to an UpdatePanel. Adding an update panel to a specific FormView template will display the data but will not return the modified data. To get around this problem we used the UpdatePanel which spans all the templates including the FormView. I never got a chance to investigate this.
 
Scenario 2: What happens when we can’t map the behavior of a control to a specific Template Mode?  In a complex page layout it might become really difficult to group a list of controls into one of the pre-defined template modes. Update / Insert / Delete commands couldn't be used in our reference implementation and the requirement stipulated the use of a separate button (outside of a FormView/GridView) which would invoke these actions(update/Insert/delete) programmatically on a combination of FormView(s)/GridView(s) to achieve the desired behavior. Since we cannot adhere to template modes, it becomes really difficult to deal with insert mode when 1) Some of the dropdowns need to be pre-selected with bunch of values 2) Displaying an empty value when bound to a value type because of a business requirement. For example, binding a Date value to TextBox with an empty string as the default text in the insert template mode is impossible unless we make the bounded property nullable.
 
Scenario 3: What happens when the validation fails on a single FormView in a complex page layout? When the input validation fails because of business rules or some other reason, it’s too late to handle the OCDS_Updating event to specify the cancel event and this would force a Re-Bind of data and thus losing the user entered data. This has to be handled at FormView_Updating event for it to hold back the state of the controls. Since we had a complex page layout with multiple FormView/GridView controls, this was a huge problem keeping the state of the page intact when a validation fails in any of the FormView/GridView controls. To avoid this issue we changed the default behavior to retain the state unless specified explicitly that the operation is completed, by extended the FormView and GridView controls.
 
Scenario 4: What effect does formatting have on the databinding? When a field is formatted for better readability (currency formatting for instance), OCDS fails while converting a string to a value type. We had to extend the implementation of OCDS to look for a TypeConverterAttribute, to handle these kinds of Type mismatches. CurrencyConverter is one of the converters that we re-use a lot in our domain model.
 
 Scenario 5:  How to filter the data in a list depending on a criterion before binding? In order to minimize the code-behind code, custom controls / types can be created to handle filtering criteria that could later be bound to a datasource. For example creating a new Custom dropdownlist which exposes a property called filterexpression can be used to later work with a datatable.select(filterexpression) to conditionally filter the data without adding a single line of code-behind code.
 
Scenario 6: How can we wire-up the events for a control which is embedded in a FormView without using FindControl? This can be easily achieved by specifying the events in the markup with the corresponding code-behind method name.
  
If any of you found a better way to solve the above problems  or run into other set of issues with databinding, please drop a line in the comments.
 
On a different note some of the nice to have implementations when using OCDS:
 
IsDirty functionality: One of the common requirements while developing a User Interface is to check if the user added/ modified/ deleted data and act accordingly. Since OCDS databinding provides two copies of data (before and after), it becomes real simple to compare the values and deduce if a value has been changed or not.
 
 
Custom controls:  Code reusability for common scenarios can be enforced seamlessly with two-way databinding by creating custom controls. This would tremendously help getting around some of the challenges posed by two-way binding. For example, in our reference implementation a lot of dropdown lists are bound to enumerations in most of the pages. Instead of doing the type conversions every time we have created EnumDropdownList by extending the DropdownList and encapsulated the type conversion logic from a string to the specified enumeration in it. Note that this can also be achieved by the TypeConverters which I have talked about earlier, but this implementation is cleaner and works towards the principle of separation of concerns.
 
Binding to an abstract class: When you have a requirement to bind to an abstract class (Since the specific values might vary at runtime), TypeConverters can be used to specify a default concrete implementation for the OCDS to work with.
 
Hope this helps!
 
 
Posted on Wednesday, March 17, 2010 9:16 PM ASP.NET | Back to top


Comments on this post: Two-way data binding in ASP.NET - Part 2

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © panpra | Powered by: GeeksWithBlogs.net