Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Implementing Two-Way Control Binding for Web Forms : Page 7

ASP.NET's native data binding provides only one-way data binding. With a little bit of effort, it's possible to extend the native functionality and provide flexible two-way data binding and a few other simple enhancements that drastically reduce the amount of code you have to write for binding data to controls.


advertisement
A Few More Odds and Ends
During the process of subclassing and dealing with data binding, it's also useful to address some things that just don't quite seem to work right in ASP.NET. For example, ListBoxes do not persist their SelectedValue unless you use ViewState, which is very annoying if you don't want to ship the content of your lists over the wire each time. This is actually quite easy to fix with this bit of code:

override protected void OnLoad(EventArgs e) { base.OnLoad(e); // Handle auto-assigning of SelectedValue so we // don't need ViewState to make this happen if (!this.EnableViewState && this.Page.IsPostBack) { string lcValue = this.Page.Request.Form[this.ID]; if (lcValue != null) this.SelectedValue = lcValue; } }

You no longer need ViewState to post back the selected value.

Another problem I ran into on several administrative forms is that passwords in text boxes are not posted back to forms. This is possibly not a bad idea, but can be a problem when you really need to post a password back for administrative purposes and you don't want users to retype the password each time. Try this:

override protected void OnLoad(EventArgs e) { base.OnLoad(e); // Post back password values as well if (this.TextMode == TextBoxMode.Password) this.Attributes.Add("value", this.Text); }

A Few Limitations
Ok, all of this stuff probably sounds pretty good to you right about now. But be aware that there are a few limitations to what I've shown you so far.

Binding doesn't work against indexed objects or properties.

  • You can't bind against collections or arrays or any member that resolves through collections or arrays. For example, you can bind to a DataRow if you have a simple property that points at this DataRow (such as the Customer.DataRow in my examples), but you cannot bind to it with Customer.DataSet.Tables["wws_Item"].Rows[0].
  • All resolving will fail if an enumerated type is encountered. This can be fixed with some changes to the reflection wrappers, but there isn't room to cover that here. Although this seems like a big deal, you can always work around this by using wrapper properties either on your form or your objects. If you look at the sample code, I expose an InvTable property on the form to bind against the table, for example. The code simply sets this property when the table is loaded.
  • Binding to private members is not possible. Because all binding occurs inside an external class, private members are not accessible for reflection. This means any objects you bind to must be protected or public.
  • Subclassed controls don't work well with child templates. If you subclass controls like the ListBox or DropDownList and manually assign values in the HTML template, you'll find that, because of the type prefix for the control, standard template expressions don't show IntelliSense. So although you can continue to use <asp:ListItem> from within <ww:wwWebDropDownList>, you will not get IntelliSense. On the other hand, if you do a lot of stuff with templates manually, you probably don't need data binding anyway. In that case, just use the stock controls.
None of these are showstoppers, but they are things you should be aware of before you take this path.

Although it's disappointing that ASP.NET doesn't include better data binding support natively, it also says a lot for the architecture that you can extend controls easily enough to provide this functionality with relatively little code. Most serious developers will end up subclassing the stock controls anyway, and adding this stuff in is only a small additional step.

You can do a lot more with the basic extensions I've built here. For example, I think you could build better input formatting into this stuff, providing things like InputMasksthat you could handle client-side. ASP.NET provides Validation controls, but again, the design is generally more work than it needs to be. I'd like a single Validation property. In any case, there are many other extensions that would be useful, but I hope you use this base and extend it. If you end up enhancing this stuff, please drop me a line so I can check it out.



Rick Strahl is president of West Wind Technologies in Maui, Hawaii. The company specializes in Web and distributed application development and tools with a focus on Windows Server Products, .NET, Visual Studio, and Visual FoxPro. Rick is author of West Wind Web Connection, a powerful and widely-used Web application framework for Visual FoxPro, and West Wind HTML Help Builder. He's also a Microsoft MVP, and a frequent contributor to magazines and books. He is co-publisher of CoDe Magazine, and his book, "Internet Applications with Visual FoxPro 6.0," is published by Hentzenwerke Publishing.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date