M2kDataBinderControlExtender:
Originally this was an alternative to placing single valued fields in FormView containers. The VS2005-2008 MS databinding changes mandated that a table be bound to a FormView and that textboxes and such in that FormView could then be bound to a field in that table. There are a bunch of things I find objectionable here.
Anyway, I stole the code for this extender from Rick Strahl at WestWind (Hawaii, poor chap), a great source for .Net intelligent thought http://www.west-wind.com/weblog/. The databinder moves fields into and out of datasets from web controls.
Visual Studio 2003 only did one way binding using the ‘eval’ method, and we had to write code to move data back. VS 2005/8 added the ‘bind’ method to move data from web controls back into datasets.
I prefered the method name ‘Fill’ to describe moving fields into the dataset. The name was always used in DataAdapters to mean moving the fields into the dataset from the datasource. So I chose to use the DBCE.Fill expression to request the databinder to fill up the dataset with field values from web controls.
While working on the m2kScrolledSetControlExtender I enhanced this extender to bind fields from dataset to columns in a JSON array stored in a hidden field (Bind To Client). The scrolledset then moves fields between a hidden field and textboxes inside the browser using javascript. The hiddenfield acts like FILE.ITEM(1) providing working storage at the browser end. Together these extenders manage the transmission from datasets to scrolledsets and back.
Since then, based on application work by the development team, I have been adding additional support in the data binder for other situations like an easy way to bind SA MV sets to multi-line textboxes and just lately support for RadioButtonLists.
The Microsoft databinding patterns can still be used and, in fact, for grid displays and other sorts of table level binding I expect we will continue to use ObjectDataSource controls.
M2kScrolledSetControlExtender:
My original goal for the scrolled set extender was to create a way to have scrolled set processing in web pages that matched the keyboarding and development efficiencies of SUB.MT500 and SCROLL.MAINT. Yeah, not quite there yet :)
In one sense the scrolled set extender stands in for SCREEN.BUILD C4. It provides a design time place for the developer to specify scrolled set behavior. It also serves to emit the required javascript for instantiating a javascript object with the operational mechanics implementing the scrolled set experience. The definition for the javascript object and all of its methods actual exists in roiGlobal.js. The scrolledset extender just needs to create an object of that class in the browser world and initialize it with parameters supplied by the application developer.
One of the principal design decisions was to leverage all the data entry power of the roiTextBox, and to loosely package an arbitrary number of entry fields in a table that would contain the set entry controls and display cells. I wrote up a how to with more details on creating scrolled sets named WEB.SCROLLED.SET and added it to the SYS.WEB.HOWTOS menu.
M2kMetaDataControlExtender:
This extender is basically a re-write of the EditParams features that we originally built into roiTextBox and the metadata data access component. It provides PMT like definitions that developers can use to describe the behavior they want and then the Tools layer can take care of the implementation.
When Microsoft broke the component design surface into a separate tab in Visual Studio 2005/2008 they COMPLETELY isolated WebControl design time from Data Access Component design time. This meant that the roiTextBox had no way of talking to the typed datasets or the metadata component. So the whole metadata world and the databinding got shoe-horned into “WebControls” (which the control extenders are) so they can sit in the same designer and interact with webcontrols.
