Limitation of FormView Control?

[Mark Olbert]

It appears that FormView controls require the >>exact<< same layout of controls and control types in the various templates in order
to function properly. Failure to do so results in a "failure to load ViewState" exception when a mode change occurs.

Is this correct?

If so, it would appear to defeat the >>entire point<< of being able to use customized templates for the various modes.

Assuming this limitation exists, what's the workaround? For example, in my current application, I have various lookup fields that
can only take on certain values. I want those to display as Labels in ReadOnly mode, and as DropDownLists in Edit and Insert mode.
Do I have to override the LoadViewState method for the page and map the control values back and forth? Or just jettison ViewState
for the FormView and rebind the control on every postback?

As an aside, I did not see any mention of this limitation in the docs. It should have been mentioned in screaming dayglo orange 18
point type.

- Mark

 

[Guest]

Hi again Mark,

No because each template is independent so viewstates for different
templates do not interfere with each other.

 

[mark]

Milosz,

The workaround I'm using is to turn off ViewState for the FormView
control, and then rebind it on every postback. Since the FormView
never tries to load its state from ViewState the problem of the
controls and control layout being different doesn't arise.
Fortunately, the overhead associated with databinding the FormView in
my application is pretty low.

But it still seems like a kludgy or incomplete solution/approach.
After thinking about it a bit, I got to wondering why the FormView
doesn't support a set of "mapping" properties that indicate which
controls relate to controls in other templates, e.g.,

....
</FieldMap>

Granted, validating the configuration information would be a bit of a
bear, but that's what software developers are for .

On a related subject, do you happen to know why using "old style"
databinding (i.e., assigning a source to DataSource and calling
DataBind(), as opposed to using DataSourceID) is a second-class
citizen when it comes to retrieving field values in the event
handlers? Given that the bindings are set up by calls to Bind() it
seems to me the FormView "knows" which control relates to which
database fields, regardless of whether new style or old style
databinding is being used. As a user of the "old style" it's a pain in
the butt to have to manually extract the field values in the event
handlers (FYI, I use the old approach because I tend to like to be
able to control when and where databinding takes place; the new style,
from what I can see, has databinding take place whenever the page
"wants" to databind, and I'd have to cancel the databinding in
situations where I don't want it done).

- Mark

 

[Walter Wang [MSFT]]

Hi Mark,

From the symptom of the issue you described, it's similar to one of known
issue of FormView when following conditions are met:

1) Uses different controls or different order in FormView's ItemTemplate
and EditItemTemplate
2) Hide the FormView in its ItemUpdated event

The workaround to this is to set DefaultMode of FormView to Edit. Let me
know whether or not this is the case.

In ASP.NET 2.0, although we offered two different ways of binding:
DataSource vs. DataSourceID, under the hood of data-bound controls data
retrieval occurs in just one way--through data source view objects. If the
control is bound to a data source control, the incorporated data source
view object is retrieved via the members of the IDataSource interface. If
the control is bound to an enumerable object, a data source view object is
dynamically built. If the DataSource is non-empty, the bound object is
wrapped in a dynamically created data source view object of type
ReadOnlyDataSource--an internal and undocumented class. Comparing to
SqlDataSourceView or ObjectDataSourceView, this readonly data source view
object is rather limited.

Hope this helps.

Regards,
Walter Wang ([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Hi Mark,

In addition to Walter’s reply, if you are curious what actually happens
under the mask, get yourself a good disassembler (i.e. Reflector that is
available for free at this address http://www.aisto.com/roeder/dotnet/) a
have a look at System.Web.UI.WebControls. BindableTemplateBuilder class.

Regards

Milosz

 

[Guest]

:

On a related subject, do you happen to know why using "old style"
databinding (i.e., assigning a source to DataSource and calling
DataBind(), as opposed to using DataSourceID) is a second-class
citizen when it comes to retrieving field values in the event
handlers?

<snip>

In my opinion, I think the DataBound controls in 2.0 just give you a
low-cost alternative for quickly creating RAD style apps/prototypes. I don't
think they are meant for all cases. In situations where the default
behaviors of the DataBound controls are adequate, they are a good choice
(kind of like MS's answer to scaffolds in Ruby).

In cases where you need to really control how your binding works, I think
you'll spend more time kludging around with DataBound control (FormView),
than it would take to create your own out of a MultiView. Personally, I'd
use DataBound controls for read-only data (GridViews), FormViews for low-cost
apps/prototypes where you have control over the requirements, and manual
binding for most other cases.

I'm curious what people are doing,
Jason Vermillion