Best Practice with Custom Controls and Event Model

Discussion in 'ASP .Net Building Controls' started by Hannes Schmiderer, Oct 9, 2003.

  1. We are using different kind of controls. Besides the basic controls we
    use (container) controls consisting of other controls. To have more
    flexibility they are not user controls but custom controls.

    The first question is, if we should explicitely assign IDs to the
    controls contained within these container controls (We use
    INamingContainer)? At the moment we usually let ASP.NET choose the
    IDs, but this often leads to errors if the control tree is not exactly
    the same after the postback.

    At the moment the controls create their child controls in
    CreateChildControls including the HTML code.(HtmlTable etc...).
    Render() ist not used with these container controls.

    The problem is that on postback CreateChildControl is called right
    after Page_Load when the post data is loaded into the dynamic controls
    (2nd try). But this is only used to get the posted values into the
    controls - often not for rendering. In the button click events
    properties of the controls are changed. The child controls have to be
    cleared (Controls.Clear(), ChildControlsCreated = false) and are
    rebuild in CreateChildControls which is called with the PreRender

    And sometimes with the call of Controls.Clear() not all controls are
    removed. When they are rebuild in the second call of
    CreateChildControls then there are two controls with the same name
    which leads to an error if trace is activated. I have not definitely
    determined when and how this occurs. Maybe when a reference still
    points to the control.

    The next problem is, if database entries control the appearance of the
    controls (differen child controls etc). For instance if the data has
    changed after postback. When the Control is rebuild at the postback it
    may have additional child controls und such .NET cannot assign the
    post values to the controls (especially when we have not assigned the
    controls id by ourselves).

    So I assume this is a case for the viewstate. But I have not really
    got how the viewstate works. Which property does the viewstate save?
    Usually the text property. If I'm right, it does not safe the
    childcontrols of controls. They have to be created manually. So we
    have to safe the appearance of a control manually in the viewstate (or
    the data which controls the appearance of the control) manually.

    I've read (and seen) that the repopulation of the controls properties
    of the viewstate only works, if the controls are created (or child
    controls added) at the init state. On the other hand I have read that
    child controls should be created in CreateChildControl, and if a page
    depends on the time CreateChildControl is called, there is something
    wrong with it. A bit wired for me.

    My current plan is, to have my own "viewstate" (and deavtivate the one
    from .NET). So I have more control over it. I will safe the appearance
    of the controls (or the data which defines its appearence) in my onw
    "viewstate" if necessary. Then I will try to create only the controls
    holding data in CreateChildControls. Everything else (Tables, etc.)
    should be build in Render() and RenderChildren() with the
    HtmlTextWriter. Don't know right now if this is at least partway
    convenient. But so we have to deal with much less controls in the
    control tree. It should be easier to manipulate the child controls of
    a control.

    Two further things I'm not really satisfied with: User controls are
    too less flexible, so we use custom controls. But so we cannot benefit
    of code behind. It's not even possible to add the container controls
    to the aspx file, because in this case .net thinks they are static and
    tries to populate the values from the post data before the page_load
    where we usually load the data for the controls which defines the
    child controls. Is it better to load this in the init state?

    The second thing ist that to go the ASP.NET way often the control tree
    has to be created only to fetch one simple post data (or only a button
    click) and then rebuild it after the properties have changed after a
    button click or anything.

    Is it reasonable to program around in some cases? For instance
    by reading the post data directly (if only a button click or some few
    values are important) and so avoiding the first CreateChildControls()?

    Any commets or links to articles welcome. Most of those tutorials or
    examples I read did not deal with the whole complexity.
    Hannes Schmiderer, Oct 9, 2003
    1. Advertisements

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. Earl Teigrob
    John Saunders
    Jun 10, 2004
  2. =?Utf-8?B?TSBL?=

    Best Practice, creating a composite of controls

    =?Utf-8?B?TSBL?=, Nov 24, 2004, in forum: ASP .Net
    Nov 24, 2004
  3. Laurent Bugnion

    Custom controls settings, best practice question

    Laurent Bugnion, Aug 26, 2006, in forum: ASP .Net
    Laurent Bugnion
    Aug 26, 2006
  4. Replies:
    Andreas Wollschlaeger
    Oct 6, 2006
  5. HP
  6. rodchar
    Nov 26, 2007
  7. snacktime
    Robert Klemme
    Oct 13, 2005
  8. oldyork90
    Jeremy J Starcher
    Sep 10, 2008