Limitation of FormView Control?

Discussion in 'ASP .Net' started by Mark Olbert, Feb 13, 2007.

  1. Mark Olbert

    Mark Olbert Guest

    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
     
    Mark Olbert, Feb 13, 2007
    #1
    1. Advertising

  2. Hi again Mark,

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

    --
    Milosz


    "Mark Olbert" wrote:

    > 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
    >
     
    =?Utf-8?B?TWlsb3N6IFNrYWxlY2tpIFtNQ0FEXQ==?=, Feb 14, 2007
    #2
    1. Advertising

  3. Mark Olbert

    Guest

    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>
    <MapEntry ReadOnlyControl="a" EditControl="b" InsertControl="c" /
    >

    ....
    </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
     
    , Feb 14, 2007
    #3
  4. 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 (, 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.
     
    Walter Wang [MSFT], Feb 14, 2007
    #4
  5. 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

    --
    Milosz


    "Walter Wang [MSFT]" wrote:

    > 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 (, 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.
    >
    >
    >
    >
     
    =?Utf-8?B?TWlsb3N6IFNrYWxlY2tpIFtNQ0FEXQ==?=, Feb 14, 2007
    #5
  6. "" wrote:
    <snip>
    >
    > 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
     
    =?Utf-8?B?SmFzb24gVmVybWlsbGlvbg==?=, Feb 14, 2007
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Anil Kulkarni

    Data grid control limitation

    Anil Kulkarni, Jul 29, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    401
    Anil Kulkarni
    Jul 29, 2003
  2. John R. Lewis
    Replies:
    0
    Views:
    705
    John R. Lewis
    Jan 4, 2006
  3. =?Utf-8?B?eXVjaGFuZw==?=
    Replies:
    0
    Views:
    539
    =?Utf-8?B?eXVjaGFuZw==?=
    Apr 15, 2006
  4. Chris

    Formview within Formview

    Chris, May 19, 2007, in forum: ASP .Net
    Replies:
    0
    Views:
    584
    Chris
    May 19, 2007
  5. David Thielen

    FormView/Repeater/ Eval(FormView data)

    David Thielen, Jun 16, 2006, in forum: ASP .Net Web Controls
    Replies:
    2
    Views:
    711
    David Thielen
    Jun 16, 2006
Loading...

Share This Page