H
Homer J. Simpson
A few weeks ago I asked for suggestions on how to persist a tree's node
state to cookies, without causing postbacks on each click in the tree.
I had a single .aspx file, with a row of buttons on top of the screen, and a
tree control below (with EnableViewState set to true). I let the user
expand/collapse away to his hearts content without needless roundtrips.
When the user clicked on a button at the top, I'd reload the page, check
IsPostBack in my Page_Load(), and if true, I'd enumerate the nodes and get
their current state at that time. I'd then set a cookie with a bool for
each node that had a child (using TreeNode.Value as the cookie name), and
added it to the response.
Each button at the top would cause the tree to then get cleared, and
repopulated with a different data set. Since the response included the
cookie, the tree's state (for the previous 'page') would then get sent back
to the client at that time, and it would be included again when the user
came back to the first page, so when re-rendering the tree, I'd check the
cookie and either call TreeNode.Expand() or .Collapse(). The flow is
probably easier to follow with code rather than me describing it. ;-)
This page has now grown in size (I've added more buttons, that reload the
page and display different data), so I've decided it would make sense to
split it apart so each button at the top of the screen would load a
different .aspx file. Since those buttons are common to each page, I put
them in a Master page and use them to nagivate from page to page, instead of
navigating to the same page with a different query value (that I then used
in a switch statement).
Not every page necessarily has the exact same content and layout, so I
thought it wouldn't make sense to put the tree in the master page as well.
Previously, when I had a single page, I would hide or show the tree as
needed. This didn't cause any harm for my cookie state.
So...now that everything's been split, in my content pages' Page_Load(), I
can get back to the tree using PreviousPage.Controls and hunt for it by ID,
and (if it exists at all) get its state and set the cookie just as I did
before...only, the nodes' expanded state doesn't match what the user had
selected when he switched from Page A to Page B--it looks like I'm getting
back the state the tree was in when Page A was *first* sent to the
client...not the state it was in when clicking one of the buttons to
navigate elsewhere...which does me no good.
I'm not sure why that's the case--*shouldn't* the new state be reflected in
PreviousPage.Controls()? If so, have I missed something obvious (or
not-so-obvious) when I transitioned from this single-page architecture to
multiple-pages?
state to cookies, without causing postbacks on each click in the tree.
I had a single .aspx file, with a row of buttons on top of the screen, and a
tree control below (with EnableViewState set to true). I let the user
expand/collapse away to his hearts content without needless roundtrips.
When the user clicked on a button at the top, I'd reload the page, check
IsPostBack in my Page_Load(), and if true, I'd enumerate the nodes and get
their current state at that time. I'd then set a cookie with a bool for
each node that had a child (using TreeNode.Value as the cookie name), and
added it to the response.
Each button at the top would cause the tree to then get cleared, and
repopulated with a different data set. Since the response included the
cookie, the tree's state (for the previous 'page') would then get sent back
to the client at that time, and it would be included again when the user
came back to the first page, so when re-rendering the tree, I'd check the
cookie and either call TreeNode.Expand() or .Collapse(). The flow is
probably easier to follow with code rather than me describing it. ;-)
This page has now grown in size (I've added more buttons, that reload the
page and display different data), so I've decided it would make sense to
split it apart so each button at the top of the screen would load a
different .aspx file. Since those buttons are common to each page, I put
them in a Master page and use them to nagivate from page to page, instead of
navigating to the same page with a different query value (that I then used
in a switch statement).
Not every page necessarily has the exact same content and layout, so I
thought it wouldn't make sense to put the tree in the master page as well.
Previously, when I had a single page, I would hide or show the tree as
needed. This didn't cause any harm for my cookie state.
So...now that everything's been split, in my content pages' Page_Load(), I
can get back to the tree using PreviousPage.Controls and hunt for it by ID,
and (if it exists at all) get its state and set the cookie just as I did
before...only, the nodes' expanded state doesn't match what the user had
selected when he switched from Page A to Page B--it looks like I'm getting
back the state the tree was in when Page A was *first* sent to the
client...not the state it was in when clicking one of the buttons to
navigate elsewhere...which does me no good.
I'm not sure why that's the case--*shouldn't* the new state be reflected in
PreviousPage.Controls()? If so, have I missed something obvious (or
not-so-obvious) when I transitioned from this single-page architecture to
multiple-pages?