Table Creation Question

  • Thread starter Thread starter Jeff
  • Start date Start date
J

Jeff

....still new to visual studio 2005 and vb.net

I have a master page with a content placeholder.

The content page has a table in the content placeholder (placed there via
dragging from the toolbox).

In the content page I created - using code - a few rows within the table and
a few cells within the rows and some text within the cells.

All works fine until the page posts back. ...and then the table reverts back
to the way it was prior to when the code added the rows, cells, etc.

What do I need to do to maintain the state of the table across postbacks?

Thanks

Jeff
 
Jeff said:
...still new to visual studio 2005 and vb.net

I have a master page with a content placeholder.

The content page has a table in the content placeholder (placed there via
dragging from the toolbox).

In the content page I created - using code - a few rows within the table
and a few cells within the rows and some text within the cells.

All works fine until the page posts back. ...and then the table reverts
back to the way it was prior to when the code added the rows, cells, etc.

What do I need to do to maintain the state of the table across postbacks?
Click to expand...


You have to load the table on a Postback. The Table's Viewstate only holds
property data like Hight and Width etc and doesn't hold data in rows and
cells, on the round trip.
 
Mr. Arnold said:
You have to load the table on a Postback. The Table's Viewstate only holds
property data like Hight and Width etc and doesn't hold data in rows and
cells, on the round trip.
Click to expand...


Yes, I noticed that all works well when I reload the table, and even the
radio buttons that I've inserted into the table maintain state after the
entire table is reloaded. ...but this table is relatively complex and so I
am wondering whether reloading the entire thing requires a corresponding
increase in the server load (i.e., doubling the actual amount of time
required to load the table on each page) or if there is something behind the
scenes that somehow eliminates this? ...and does it matter if I create the
rows and cells within the interface or via code? If I create them and add
text or other content by altering the table via the
interface/properties-window, they do remain after a postback, but perhaps
this is still requires the same server-processor load but the work being
performed is simply hidden to me.

Can anyone clarify?

Jeff
 
Jeff said:
Yes, I noticed that all works well when I reload the table, and even the
radio buttons that I've inserted into the table maintain state after the
entire table is reloaded. ...but this table is relatively complex and so
I am wondering whether reloading the entire thing requires a corresponding
increase in the server load (i.e., doubling the actual amount of time
required to load the table on each page) or if there is something behind
the scenes that somehow eliminates this? ...and does it matter if I
create the rows and cells within the interface or via code?
Click to expand...

It doesn't make any difference whether you do it in code or not, the table
is not going to hold state on rows and cells on the round trip from client
to server. You have to reload it each time. It's the nature of the beast.
Anytime you do a postback, it's a load on the server no matter what you're
doing. That's why they have Web server farms with load balancing, to spread
the wealth sort of speaking.

If I create them and add text or other content by altering the table via
the interface/properties-window, they do remain after a postback, but
perhaps this is still requires the same server-processor load but the work
being performed is simply hidden to me.
Click to expand...

You must be talking about the Viewstate, which is still the same thing.

A control's Viewstate must be sent over the wire on the round trip, which
can slow things down. It's as simple as that. Each time on the round trip
between the client and the server, the page must be rebuilt, because it's a
stateless session. The less you have on the server side on rebuilding
things, the better it is for the client. But some things are unavoidable
with Web forms.

That's way solutions such as Ajax Pro for .NET exist, which is free is being
used in .NET solutions to avoid the postback altogether, with calling back
to the Code Behind file with no postback. Things are done on the client side
with JavaScript with the Code Behind file only being used as a proxy/utility
for holding object state in a session or accessing a database, things of
that nature. There are no Web controls on the form.

Even .NET 2005 and ASP.NET have this callback with no postback feature like
Ajax Pro to use the Code Behind File.

http://www.codeplex.com/AjaxPro
http://msdn.microsoft.com/msdnmag/issues/04/06/ASPNET20Overview/default.aspx#S15

There should be plenty of examples out there on Google for the above two
solutions on how to use them.
 
It doesn't make any difference whether you do it in code or not, the table
is not going to hold state on rows and cells on the round trip from client
to server. You have to reload it each time. It's the nature of the beast.
Click to expand...


I think I understand. Let me ask this to confirm.

I use code (in a - is not page.ispostback if/then construct) to populate a
listbox (created using the graphic interface) with a number of rows. I do
similar to place a number of radiobuttons in a table that is also created in
the interface. When the page is posted-back, the viewstate of the listbox
remains (the actual box and the user's selection) but the contents of the
table with the radiobuttons completely disappear unless I take the code
creating the table out of the not-postback sub and run it again in the page
load sub. Then, the table is re-created and the user's radiobutton selection
remains. ...but rather than create the table/radiobuttons by code, I could
do most of this through the graphical interface, in which case the table
does not disappear on postback.

....so if I understand you correctly, in all cases for both the listbox and
radiobuttons/table the server will perform essentially the same tasks by
going through the same steps to recreate both the listbox and table
regardless of whether or not these steps/tasks are visible through the
written code, or occur due to my selections in the
interface/properties-window ? ...but for whatever reason, the listbox and
table behave differently when I create/alter them by code, so for the table
I have to explicitly reload the thing, and for the listbox, the underlying
server application does this without me being aware?

Is this essentially correct?

Thanks

Jeff
 
Jeff said:
I think I understand. Let me ask this to confirm.

I use code (in a - is not page.ispostback if/then construct) to populate a
listbox (created using the graphic interface) with a number of rows. I do
similar to place a number of radiobuttons in a table that is also created
in the interface. When the page is posted-back, the viewstate of the
listbox remains (the actual box and the user's selection) but the contents
of the table with the radiobuttons completely disappear unless I take the
code creating the table out of the not-postback sub and run it again in
the page load sub. Then, the table is re-created and the user's
radiobutton selection remains. ...but rather than create the
table/radiobuttons by code, I could do most of this through the graphical
interface, in which case the table does not disappear on postback.

...so if I understand you correctly, in all cases for both the listbox and
radiobuttons/table the server will perform essentially the same tasks by
going through the same steps to recreate both the listbox and table
regardless of whether or not these steps/tasks are visible through the
written code, or occur due to my selections in the
interface/properties-window ? ...but for whatever reason, the listbox and
table behave differently when I create/alter them by code, so for the
table I have to explicitly reload the thing, and for the listbox, the
underlying server application does this without me being aware?

Is this essentially correct?
Click to expand...

Here is the ASP.NET page Life Cycle. It's got to do it every time, no matter
what. It's got to happen every time the same way no matter what.

http://www.15seconds.com/issue/020102.htm

I suggest that you understand what's happening with a Web application using
a browser. Everything is stateless and must be rebuilt every time you use a
control that does a post. That's all the controls must be rebuilt on the
page, not just the one you're dealing with at the time.

http://www.adiscon.com/IIS/isapi005.htm

If a control is holding some kind of state like Viewstate, then think about
the time it takes to send that Viewstate data with the control to the client
and back to the server to keep its state, particularly if you have large
amounts of data keeping Viewstate in some kind of grid or table control.

In most cases, it better to not keep the Viewstate and just load the data
back on the postback, instead of sending that data with the control to and
from the client on the round trip.
 
Here is the ASP.NET page Life Cycle. It's got to do it every time, no
matter what. It's got to happen every time the same way no matter what.'
Click to expand...

Thanks. I put the code in to re-load the table after a postback. ...seems to
work fine and I can't detect any noticable decrease in speed relative to
loading a page without a table of this type. ...course that's only one user
over a dsl connection.

Jeff
 
Back
Top