H
Hannes Schmiderer
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
event.
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 asp.net 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.
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
event.
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 asp.net 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.