How to avoid lifecycle hacks?

The ASP.NET model is touted as a clean OO approach to developing web pages,
yet sometimes the page lifecycle poses silly obstacles that forces you revert
to the Olde ASP 3.0 Ways.

Here's a rough outline of an ASPX page:

.... a bunch of criteria controls...
PagingNav
ResultSetDisplay
SubmitButton

Basically, the PagingNav allows the user to navigate through the DB result
set; the ResultSetDisplay shows the currently selected page in a data list;
and the SubmitButton is used in case the user changed criteria and wants to
update the view.

Now, the PagingNav control needs to know the total number of records found
in the DB, so the query must be exectued before it's rendered. Therefore I
have to execute the query before the PreRender event of PagingNav, which
means I cannot, for example, execute the query in the PreRender event of the
ResultSetDisplay control since it will be executed after the PreRender event
of the PagingNav control (due to its position in the page). In other words,
it would be too late for the PageNavControl to figure out the total records
the query found. I can execute the query in any event of ResultSetDisplay
that fires before PreRender. So far so good.

Enter the SubmitButton control, which messes up the whole plan. The problem
is, I want to reset the current page number to 1 whenever this button is
clicked. So I add code to do that in its SubmitButton_Click. Alas, this event
executes AFTER the Load event of the ResultSetDisplay and BEFORE its
PreRender event. This means to get the ResultSetDisplay to dispay the
appropriate page (i.e. # 1), I have to excute the query in an event that
takes place after the SubmitButton_Click event, which is the PreRender event.
But that pretty much screws up the PagingNav control since, as explained
above, it needs to find out how many records the query found, but it's too
late now.

So, to fix the problem, I have to revert to ASP 3.0 hacks and add something
in the Load event of the ResultSetDispay such as:

if (Request.Form["update"] != null)
this.currentPage = 1;

which is totally against the OO style of ASP.NET.

So my question is, how would you guys solve such a problem neatly?

re: How to avoid lifecycle hacks?

Hi,

I would create a base page class and derive my pages from this class. The
base page's Page_Load event will fire first, you can then hit your data
access and business logic layers here. Retrieving the data you need and
setting custom properties for derived classes to check before they render.

I would also recommend buying some books on OOP and studying them carefully.
You attempted to solve your problem using an almost top-down approach. When
you are trying to implement an OO design you know you are on the wrong path
when you try to rig things up after the fact. Always try to think what
would come first. In this case a base class will solve your problem and
also make your code much more elegant and extensible. Good luck! Ken.

--
Ken Dopierala Jr.
For great ASP.Net web hosting try:
http://www.webhost4life.com/default.asp?refid=Spinlight
If you sign up under me and need help, email me.

"Homam" <Homam@discussions.microsoft.com> wrote in message
news:A2C2B1CE-90B5-4D49-9FCF-0D9B8733CDC0@microsoft.com...[color=blue]
> The ASP.NET model is touted as a clean OO approach to developing web[/color]
pages,[color=blue]
> yet sometimes the page lifecycle poses silly obstacles that forces you[/color]
revert[color=blue]
> to the Olde ASP 3.0 Ways.
>
> Here's a rough outline of an ASPX page:
>
> ... a bunch of criteria controls...
> PagingNav
> ResultSetDisplay
> SubmitButton
>
> Basically, the PagingNav allows the user to navigate through the DB result
> set; the ResultSetDisplay shows the currently selected page in a data[/color]
list;[color=blue]
> and the SubmitButton is used in case the user changed criteria and wants[/color]
to[color=blue]
> update the view.
>
> Now, the PagingNav control needs to know the total number of records found
> in the DB, so the query must be exectued before it's rendered. Therefore I
> have to execute the query before the PreRender event of PagingNav, which
> means I cannot, for example, execute the query in the PreRender event of[/color]
the[color=blue]
> ResultSetDisplay control since it will be executed after the PreRender[/color]
event[color=blue]
> of the PagingNav control (due to its position in the page). In other[/color]
words,[color=blue]
> it would be too late for the PageNavControl to figure out the total[/color]
records[color=blue]
> the query found. I can execute the query in any event of ResultSetDisplay
> that fires before PreRender. So far so good.
>
> Enter the SubmitButton control, which messes up the whole plan. The[/color]
problem[color=blue]
> is, I want to reset the current page number to 1 whenever this button is
> clicked. So I add code to do that in its SubmitButton_Click. Alas, this[/color]
event[color=blue]
> executes AFTER the Load event of the ResultSetDisplay and BEFORE its
> PreRender event. This means to get the ResultSetDisplay to dispay the
> appropriate page (i.e. # 1), I have to excute the query in an event that
> takes place after the SubmitButton_Click event, which is the PreRender[/color]
event.[color=blue]
> But that pretty much screws up the PagingNav control since, as explained
> above, it needs to find out how many records the query found, but it's too
> late now.
>
> So, to fix the problem, I have to revert to ASP 3.0 hacks and add[/color]
something[color=blue]
> in the Load event of the ResultSetDispay such as:
>
> if (Request.Form["update"] != null)
> this.currentPage = 1;
>
> which is totally against the OO style of ASP.NET.
>
> So my question is, how would you guys solve such a problem neatly?
>[/color]

re: How to avoid lifecycle hacks?

Hi Homan:

Here is one approach:

Factor all the querying code out of the PreRender and event handlers
into a distinct method of the class, say, PopulateDataList. If I
understand your scenario you might need to pass a page number to the
method.

During the first Page_Load event (!IsPostBack) you can initially
populate the data list by calling this method. Likewise, the submit
button click event could invoke this method passing a page number of
1.

What I may not understand is the problem you are having with the
paging navigation. I'd think this navigation control would fire events
that call PopulateDataList passing the proper page number.
PopulateDataList could also inform the nav control about the total
number of records. All of this happens before the controls render and
gets you out of having code inside PreRender that has to understand
what has happened on the page.

--
Scott
http://www.OdeToCode.com/blogs/scott/

On Wed, 2 Mar 2005 17:57:03 -0800, "Homam"
<Homam@discussions.microsoft.com> wrote:
[color=blue]
>The ASP.NET model is touted as a clean OO approach to developing web pages,
>yet sometimes the page lifecycle poses silly obstacles that forces you revert
>to the Olde ASP 3.0 Ways.
>
>Here's a rough outline of an ASPX page:
>
>... a bunch of criteria controls...
>PagingNav
>ResultSetDisplay
>SubmitButton
>
>Basically, the PagingNav allows the user to navigate through the DB result
>set; the ResultSetDisplay shows the currently selected page in a data list;
>and the SubmitButton is used in case the user changed criteria and wants to
>update the view.
>
>Now, the PagingNav control needs to know the total number of records found
>in the DB, so the query must be exectued before it's rendered. Therefore I
>have to execute the query before the PreRender event of PagingNav, which
>means I cannot, for example, execute the query in the PreRender event of the
>ResultSetDisplay control since it will be executed after the PreRender event
>of the PagingNav control (due to its position in the page). In other words,
>it would be too late for the PageNavControl to figure out the total records
>the query found. I can execute the query in any event of ResultSetDisplay
>that fires before PreRender. So far so good.
>
>Enter the SubmitButton control, which messes up the whole plan. The problem
>is, I want to reset the current page number to 1 whenever this button is
>clicked. So I add code to do that in its SubmitButton_Click. Alas, this event
>executes AFTER the Load event of the ResultSetDisplay and BEFORE its
>PreRender event. This means to get the ResultSetDisplay to dispay the
>appropriate page (i.e. # 1), I have to excute the query in an event that
>takes place after the SubmitButton_Click event, which is the PreRender event.
>But that pretty much screws up the PagingNav control since, as explained
>above, it needs to find out how many records the query found, but it's too
>late now.
>
>So, to fix the problem, I have to revert to ASP 3.0 hacks and add something
>in the Load event of the ResultSetDispay such as:
>
>if (Request.Form["update"] != null)
> this.currentPage = 1;
>
>which is totally against the OO style of ASP.NET.
>
>So my question is, how would you guys solve such a problem neatly?[/color]

re: How to avoid lifecycle hacks?

Hi Ken,

This wouldn't slove my problem because even when I add an intermediate
class, the overloaded Load event will still fire before the SubmitButton's
Click event. So if the user clicked on that button to update the criteria,
the current page will be set AFTER the query has already executed, and the
ResultSetDisplay will display the wrong page.

To illustrate, let's say that the user submitted a set of criteria C1 and
browsed to page number 5 of the its result set. Then he changed the criteria
to C2 and hit the SubmitButton. Now if I execute the query in the overloaded
Load event handler in the derived class, the query will retrieve page 5 of
C2, not page 1 as it should, because the page was set in the SubmitButton
event handler after the query got executed.

By the way, the code is executed in the Code Behind class, which is derived
from Page anyway.

I'm very well versed in OOA/D/P and all the design patterns paraphernalia (I
come from a J2EE background), but I'm still trying to figure out ASP.NET's
plumbing.

Thanks for your feedback.




"Ken Dopierala Jr." wrote:
[color=blue]
> Hi,
>
> I would create a base page class and derive my pages from this class. The
> base page's Page_Load event will fire first, you can then hit your data
> access and business logic layers here. Retrieving the data you need and
> setting custom properties for derived classes to check before they render.
>
> I would also recommend buying some books on OOP and studying them carefully.
> You attempted to solve your problem using an almost top-down approach. When
> you are trying to implement an OO design you know you are on the wrong path
> when you try to rig things up after the fact. Always try to think what
> would come first. In this case a base class will solve your problem and
> also make your code much more elegant and extensible. Good luck! Ken.
>
> --
> Ken Dopierala Jr.
> For great ASP.Net web hosting try:
> http://www.webhost4life.com/default.asp?refid=Spinlight
> If you sign up under me and need help, email me.
>
> "Homam" <Homam@discussions.microsoft.com> wrote in message
> news:A2C2B1CE-90B5-4D49-9FCF-0D9B8733CDC0@microsoft.com...[color=green]
> > The ASP.NET model is touted as a clean OO approach to developing web[/color]
> pages,[color=green]
> > yet sometimes the page lifecycle poses silly obstacles that forces you[/color]
> revert[color=green]
> > to the Olde ASP 3.0 Ways.
> >
> > Here's a rough outline of an ASPX page:
> >
> > ... a bunch of criteria controls...
> > PagingNav
> > ResultSetDisplay
> > SubmitButton
> >
> > Basically, the PagingNav allows the user to navigate through the DB result
> > set; the ResultSetDisplay shows the currently selected page in a data[/color]
> list;[color=green]
> > and the SubmitButton is used in case the user changed criteria and wants[/color]
> to[color=green]
> > update the view.
> >
> > Now, the PagingNav control needs to know the total number of records found
> > in the DB, so the query must be exectued before it's rendered. Therefore I
> > have to execute the query before the PreRender event of PagingNav, which
> > means I cannot, for example, execute the query in the PreRender event of[/color]
> the[color=green]
> > ResultSetDisplay control since it will be executed after the PreRender[/color]
> event[color=green]
> > of the PagingNav control (due to its position in the page). In other[/color]
> words,[color=green]
> > it would be too late for the PageNavControl to figure out the total[/color]
> records[color=green]
> > the query found. I can execute the query in any event of ResultSetDisplay
> > that fires before PreRender. So far so good.
> >
> > Enter the SubmitButton control, which messes up the whole plan. The[/color]
> problem[color=green]
> > is, I want to reset the current page number to 1 whenever this button is
> > clicked. So I add code to do that in its SubmitButton_Click. Alas, this[/color]
> event[color=green]
> > executes AFTER the Load event of the ResultSetDisplay and BEFORE its
> > PreRender event. This means to get the ResultSetDisplay to dispay the
> > appropriate page (i.e. # 1), I have to excute the query in an event that
> > takes place after the SubmitButton_Click event, which is the PreRender[/color]
> event.[color=green]
> > But that pretty much screws up the PagingNav control since, as explained
> > above, it needs to find out how many records the query found, but it's too
> > late now.
> >
> > So, to fix the problem, I have to revert to ASP 3.0 hacks and add[/color]
> something[color=green]
> > in the Load event of the ResultSetDispay such as:
> >
> > if (Request.Form["update"] != null)
> > this.currentPage = 1;
> >
> > which is totally against the OO style of ASP.NET.
> >
> > So my question is, how would you guys solve such a problem neatly?
> >[/color]
>
>
>[/color]

re: How to avoid lifecycle hacks?

Hi Scott,

Actually the code that retrieves the result set is factored as you
indicated, and you're right, it's passed a page number. Currently I'm calling
it from the Load event handler of the ResultSetDisplay.

Your proposed solution (i.e. calling this function from either
SubmitButton's Click event handler XOR the Load event handler) requires the
same hack. That's because I have to call this function from the Load event
while making sure the SubmitButton control wasn't clicked (so that I don't
end up calling it twice, once in the Load event handler and once in the
SubmitButton's Click event handler). And there's no way of knowing during the
execution of the Load event handler if the SubmitButton was clicked other
than that hack that I mentioned in my original message. IsPostBack won't cut
it here because other controls could also submit the page (e.g. the
PagingNav), not just the SubmitButton.

Thanks for your feedback.

Homam



"Scott Allen" wrote:
[color=blue]
> Hi Homan:
>
> Here is one approach:
>
> Factor all the querying code out of the PreRender and event handlers
> into a distinct method of the class, say, PopulateDataList. If I
> understand your scenario you might need to pass a page number to the
> method.
>
> During the first Page_Load event (!IsPostBack) you can initially
> populate the data list by calling this method. Likewise, the submit
> button click event could invoke this method passing a page number of
> 1.
>
> What I may not understand is the problem you are having with the
> paging navigation. I'd think this navigation control would fire events
> that call PopulateDataList passing the proper page number.
> PopulateDataList could also inform the nav control about the total
> number of records. All of this happens before the controls render and
> gets you out of having code inside PreRender that has to understand
> what has happened on the page.
>
> --
> Scott
> http://www.OdeToCode.com/blogs/scott/
>
> On Wed, 2 Mar 2005 17:57:03 -0800, "Homam"
> <Homam@discussions.microsoft.com> wrote:
>[color=green]
> >The ASP.NET model is touted as a clean OO approach to developing web pages,
> >yet sometimes the page lifecycle poses silly obstacles that forces you revert
> >to the Olde ASP 3.0 Ways.
> >
> >Here's a rough outline of an ASPX page:
> >
> >... a bunch of criteria controls...
> >PagingNav
> >ResultSetDisplay
> >SubmitButton
> >
> >Basically, the PagingNav allows the user to navigate through the DB result
> >set; the ResultSetDisplay shows the currently selected page in a data list;
> >and the SubmitButton is used in case the user changed criteria and wants to
> >update the view.
> >
> >Now, the PagingNav control needs to know the total number of records found
> >in the DB, so the query must be exectued before it's rendered. Therefore I
> >have to execute the query before the PreRender event of PagingNav, which
> >means I cannot, for example, execute the query in the PreRender event of the
> >ResultSetDisplay control since it will be executed after the PreRender event
> >of the PagingNav control (due to its position in the page). In other words,
> >it would be too late for the PageNavControl to figure out the total records
> >the query found. I can execute the query in any event of ResultSetDisplay
> >that fires before PreRender. So far so good.
> >
> >Enter the SubmitButton control, which messes up the whole plan. The problem
> >is, I want to reset the current page number to 1 whenever this button is
> >clicked. So I add code to do that in its SubmitButton_Click. Alas, this event
> >executes AFTER the Load event of the ResultSetDisplay and BEFORE its
> >PreRender event. This means to get the ResultSetDisplay to dispay the
> >appropriate page (i.e. # 1), I have to excute the query in an event that
> >takes place after the SubmitButton_Click event, which is the PreRender event.
> >But that pretty much screws up the PagingNav control since, as explained
> >above, it needs to find out how many records the query found, but it's too
> >late now.
> >
> >So, to fix the problem, I have to revert to ASP 3.0 hacks and add something
> >in the Load event of the ResultSetDispay such as:
> >
> >if (Request.Form["update"] != null)
> > this.currentPage = 1;
> >
> >which is totally against the OO style of ASP.NET.
> >
> >So my question is, how would you guys solve such a problem neatly?[/color]
>
>[/color]

re: How to avoid lifecycle hacks?

Hi,

I think implementing a Master Pages type scenario is what you are looking
for. They are built into v2.0 of the framework but here are some link for
implementing them in v1.1:

http://www.codeproject.com/aspnet/PageFramework.asp

http://www.codeproject.com/aspnet/Frame_Work_Design.asp

Also read through this from Microsoft's Patterns & Practices:

http://msdn.microsoft.com/library/de...tml/DesMVC.asp

For your paging navigation I would recommend creating your own custom
control with all UI necessary to page (i.e. page selection links or
dropdown, submit button, previous/next links). This will allow you to make
it very generic and at the same time expose a number of custom properties
that can be changed in the property window of the IDE to customize for any
scenario. For example in one scenario you may show the current page and
links to the two pages behind or ahead of it. Where as in another scenario
you may show the page you are on, the immediate pages around it and links to
also go all the way to the beginning or end of the data. In your custom
control include the javascript necessary to set a hidden input to the
correct page when the submit button is clicked. Then have your base page
check this hidden input before loading the data. Now you'll know where to
go before the submit button click even fires. In fact, you wouldn't even
need to capture the click event on the server-side. Good luck! Ken.

--
Ken Dopierala Jr.
For great ASP.Net web hosting try:
http://www.webhost4life.com/default.asp?refid=Spinlight
If you sign up under me and need help, email me.

"Homam" <Homam@discussions.microsoft.com> wrote in message
news:C138BFAD-0487-42A5-B762-A91F16E76DA8@microsoft.com...[color=blue]
> Hi Ken,
>
> This wouldn't slove my problem because even when I add an intermediate
> class, the overloaded Load event will still fire before the SubmitButton's
> Click event. So if the user clicked on that button to update the criteria,
> the current page will be set AFTER the query has already executed, and the
> ResultSetDisplay will display the wrong page.
>
> To illustrate, let's say that the user submitted a set of criteria C1 and
> browsed to page number 5 of the its result set. Then he changed the[/color]
criteria[color=blue]
> to C2 and hit the SubmitButton. Now if I execute the query in the[/color]
overloaded[color=blue]
> Load event handler in the derived class, the query will retrieve page 5 of
> C2, not page 1 as it should, because the page was set in the SubmitButton
> event handler after the query got executed.
>
> By the way, the code is executed in the Code Behind class, which is[/color]
derived[color=blue]
> from Page anyway.
>
> I'm very well versed in OOA/D/P and all the design patterns paraphernalia[/color]
(I[color=blue]
> come from a J2EE background), but I'm still trying to figure out ASP.NET's
> plumbing.
>
> Thanks for your feedback.
>
>
>
>
> "Ken Dopierala Jr." wrote:
>[color=green]
> > Hi,
> >
> > I would create a base page class and derive my pages from this class.[/color][/color]
The[color=blue][color=green]
> > base page's Page_Load event will fire first, you can then hit your data
> > access and business logic layers here. Retrieving the data you need and
> > setting custom properties for derived classes to check before they[/color][/color]
render.[color=blue][color=green]
> >
> > I would also recommend buying some books on OOP and studying them[/color][/color]
carefully.[color=blue][color=green]
> > You attempted to solve your problem using an almost top-down approach.[/color][/color]
When[color=blue][color=green]
> > you are trying to implement an OO design you know you are on the wrong[/color][/color]
path[color=blue][color=green]
> > when you try to rig things up after the fact. Always try to think what
> > would come first. In this case a base class will solve your problem and
> > also make your code much more elegant and extensible. Good luck! Ken.
> >
> > --
> > Ken Dopierala Jr.
> > For great ASP.Net web hosting try:
> > http://www.webhost4life.com/default.asp?refid=Spinlight
> > If you sign up under me and need help, email me.
> >
> > "Homam" <Homam@discussions.microsoft.com> wrote in message
> > news:A2C2B1CE-90B5-4D49-9FCF-0D9B8733CDC0@microsoft.com...[color=darkred]
> > > The ASP.NET model is touted as a clean OO approach to developing web[/color]
> > pages,[color=darkred]
> > > yet sometimes the page lifecycle poses silly obstacles that forces you[/color]
> > revert[color=darkred]
> > > to the Olde ASP 3.0 Ways.
> > >
> > > Here's a rough outline of an ASPX page:
> > >
> > > ... a bunch of criteria controls...
> > > PagingNav
> > > ResultSetDisplay
> > > SubmitButton
> > >
> > > Basically, the PagingNav allows the user to navigate through the DB[/color][/color][/color]
result[color=blue][color=green][color=darkred]
> > > set; the ResultSetDisplay shows the currently selected page in a data[/color]
> > list;[color=darkred]
> > > and the SubmitButton is used in case the user changed criteria and[/color][/color][/color]
wants[color=blue][color=green]
> > to[color=darkred]
> > > update the view.
> > >
> > > Now, the PagingNav control needs to know the total number of records[/color][/color][/color]
found[color=blue][color=green][color=darkred]
> > > in the DB, so the query must be exectued before it's rendered.[/color][/color][/color]
Therefore I[color=blue][color=green][color=darkred]
> > > have to execute the query before the PreRender event of PagingNav,[/color][/color][/color]
which[color=blue][color=green][color=darkred]
> > > means I cannot, for example, execute the query in the PreRender event[/color][/color][/color]
of[color=blue][color=green]
> > the[color=darkred]
> > > ResultSetDisplay control since it will be executed after the PreRender[/color]
> > event[color=darkred]
> > > of the PagingNav control (due to its position in the page). In other[/color]
> > words,[color=darkred]
> > > it would be too late for the PageNavControl to figure out the total[/color]
> > records[color=darkred]
> > > the query found. I can execute the query in any event of[/color][/color][/color]
ResultSetDisplay[color=blue][color=green][color=darkred]
> > > that fires before PreRender. So far so good.
> > >
> > > Enter the SubmitButton control, which messes up the whole plan. The[/color]
> > problem[color=darkred]
> > > is, I want to reset the current page number to 1 whenever this button[/color][/color][/color]
is[color=blue][color=green][color=darkred]
> > > clicked. So I add code to do that in its SubmitButton_Click. Alas,[/color][/color][/color]
this[color=blue][color=green]
> > event[color=darkred]
> > > executes AFTER the Load event of the ResultSetDisplay and BEFORE its
> > > PreRender event. This means to get the ResultSetDisplay to dispay the
> > > appropriate page (i.e. # 1), I have to excute the query in an event[/color][/color][/color]
that[color=blue][color=green][color=darkred]
> > > takes place after the SubmitButton_Click event, which is the PreRender[/color]
> > event.[color=darkred]
> > > But that pretty much screws up the PagingNav control since, as[/color][/color][/color]
explained[color=blue][color=green][color=darkred]
> > > above, it needs to find out how many records the query found, but it's[/color][/color][/color]
too[color=blue][color=green][color=darkred]
> > > late now.
> > >
> > > So, to fix the problem, I have to revert to ASP 3.0 hacks and add[/color]
> > something[color=darkred]
> > > in the Load event of the ResultSetDispay such as:
> > >
> > > if (Request.Form["update"] != null)
> > > this.currentPage = 1;
> > >
> > > which is totally against the OO style of ASP.NET.
> > >
> > > So my question is, how would you guys solve such a problem neatly?
> > >[/color]
> >
> >
> >[/color][/color]

re: How to avoid lifecycle hacks?

Hi Ken,

Using JavaScript and hidden form fields is pretty much the same hack as
checking whether the SubmitButton exists in the form object. I'm just trying
to figure out a solution along the line of ASP.NET's event-driven, OO model.

Thanks,

Homam




"Ken Dopierala Jr." wrote:
[color=blue]
> Hi,
>
> I think implementing a Master Pages type scenario is what you are looking
> for. They are built into v2.0 of the framework but here are some link for
> implementing them in v1.1:
>
> http://www.codeproject.com/aspnet/PageFramework.asp
>
> http://www.codeproject.com/aspnet/Frame_Work_Design.asp
>
> Also read through this from Microsoft's Patterns & Practices:
>
> http://msdn.microsoft.com/library/de...tml/DesMVC.asp
>
> For your paging navigation I would recommend creating your own custom
> control with all UI necessary to page (i.e. page selection links or
> dropdown, submit button, previous/next links). This will allow you to make
> it very generic and at the same time expose a number of custom properties
> that can be changed in the property window of the IDE to customize for any
> scenario. For example in one scenario you may show the current page and
> links to the two pages behind or ahead of it. Where as in another scenario
> you may show the page you are on, the immediate pages around it and links to
> also go all the way to the beginning or end of the data. In your custom
> control include the javascript necessary to set a hidden input to the
> correct page when the submit button is clicked. Then have your base page
> check this hidden input before loading the data. Now you'll know where to
> go before the submit button click even fires. In fact, you wouldn't even
> need to capture the click event on the server-side. Good luck! Ken.
>
> --
> Ken Dopierala Jr.
> For great ASP.Net web hosting try:
> http://www.webhost4life.com/default.asp?refid=Spinlight
> If you sign up under me and need help, email me.
>
> "Homam" <Homam@discussions.microsoft.com> wrote in message
> news:C138BFAD-0487-42A5-B762-A91F16E76DA8@microsoft.com...[color=green]
> > Hi Ken,
> >
> > This wouldn't slove my problem because even when I add an intermediate
> > class, the overloaded Load event will still fire before the SubmitButton's
> > Click event. So if the user clicked on that button to update the criteria,
> > the current page will be set AFTER the query has already executed, and the
> > ResultSetDisplay will display the wrong page.
> >
> > To illustrate, let's say that the user submitted a set of criteria C1 and
> > browsed to page number 5 of the its result set. Then he changed the[/color]
> criteria[color=green]
> > to C2 and hit the SubmitButton. Now if I execute the query in the[/color]
> overloaded[color=green]
> > Load event handler in the derived class, the query will retrieve page 5 of
> > C2, not page 1 as it should, because the page was set in the SubmitButton
> > event handler after the query got executed.
> >
> > By the way, the code is executed in the Code Behind class, which is[/color]
> derived[color=green]
> > from Page anyway.
> >
> > I'm very well versed in OOA/D/P and all the design patterns paraphernalia[/color]
> (I[color=green]
> > come from a J2EE background), but I'm still trying to figure out ASP.NET's
> > plumbing.
> >
> > Thanks for your feedback.
> >
> >
> >
> >
> > "Ken Dopierala Jr." wrote:
> >[color=darkred]
> > > Hi,
> > >
> > > I would create a base page class and derive my pages from this class.[/color][/color]
> The[color=green][color=darkred]
> > > base page's Page_Load event will fire first, you can then hit your data
> > > access and business logic layers here. Retrieving the data you need and
> > > setting custom properties for derived classes to check before they[/color][/color]
> render.[color=green][color=darkred]
> > >
> > > I would also recommend buying some books on OOP and studying them[/color][/color]
> carefully.[color=green][color=darkred]
> > > You attempted to solve your problem using an almost top-down approach.[/color][/color]
> When[color=green][color=darkred]
> > > you are trying to implement an OO design you know you are on the wrong[/color][/color]
> path[color=green][color=darkred]
> > > when you try to rig things up after the fact. Always try to think what
> > > would come first. In this case a base class will solve your problem and
> > > also make your code much more elegant and extensible. Good luck! Ken.
> > >
> > > --
> > > Ken Dopierala Jr.
> > > For great ASP.Net web hosting try:
> > > http://www.webhost4life.com/default.asp?refid=Spinlight
> > > If you sign up under me and need help, email me.
> > >
> > > "Homam" <Homam@discussions.microsoft.com> wrote in message
> > > news:A2C2B1CE-90B5-4D49-9FCF-0D9B8733CDC0@microsoft.com...
> > > > The ASP.NET model is touted as a clean OO approach to developing web
> > > pages,
> > > > yet sometimes the page lifecycle poses silly obstacles that forces you
> > > revert
> > > > to the Olde ASP 3.0 Ways.
> > > >
> > > > Here's a rough outline of an ASPX page:
> > > >
> > > > ... a bunch of criteria controls...
> > > > PagingNav
> > > > ResultSetDisplay
> > > > SubmitButton
> > > >
> > > > Basically, the PagingNav allows the user to navigate through the DB[/color][/color]
> result[color=green][color=darkred]
> > > > set; the ResultSetDisplay shows the currently selected page in a data
> > > list;
> > > > and the SubmitButton is used in case the user changed criteria and[/color][/color]
> wants[color=green][color=darkred]
> > > to
> > > > update the view.
> > > >
> > > > Now, the PagingNav control needs to know the total number of records[/color][/color]
> found[color=green][color=darkred]
> > > > in the DB, so the query must be exectued before it's rendered.[/color][/color]
> Therefore I[color=green][color=darkred]
> > > > have to execute the query before the PreRender event of PagingNav,[/color][/color]
> which[color=green][color=darkred]
> > > > means I cannot, for example, execute the query in the PreRender event[/color][/color]
> of[color=green][color=darkred]
> > > the
> > > > ResultSetDisplay control since it will be executed after the PreRender
> > > event
> > > > of the PagingNav control (due to its position in the page). In other
> > > words,
> > > > it would be too late for the PageNavControl to figure out the total
> > > records
> > > > the query found. I can execute the query in any event of[/color][/color]
> ResultSetDisplay[color=green][color=darkred]
> > > > that fires before PreRender. So far so good.
> > > >
> > > > Enter the SubmitButton control, which messes up the whole plan. The
> > > problem
> > > > is, I want to reset the current page number to 1 whenever this button[/color][/color]
> is[color=green][color=darkred]
> > > > clicked. So I add code to do that in its SubmitButton_Click. Alas,[/color][/color]
> this[color=green][color=darkred]
> > > event
> > > > executes AFTER the Load event of the ResultSetDisplay and BEFORE its
> > > > PreRender event. This means to get the ResultSetDisplay to dispay the
> > > > appropriate page (i.e. # 1), I have to excute the query in an event[/color][/color]
> that[color=green][color=darkred]
> > > > takes place after the SubmitButton_Click event, which is the PreRender
> > > event.
> > > > But that pretty much screws up the PagingNav control since, as[/color][/color]
> explained[color=green][color=darkred]
> > > > above, it needs to find out how many records the query found, but it's[/color][/color]
> too[color=green][color=darkred]
> > > > late now.
> > > >
> > > > So, to fix the problem, I have to revert to ASP 3.0 hacks and add
> > > something
> > > > in the Load event of the ResultSetDispay such as:
> > > >
> > > > if (Request.Form["update"] != null)
> > > > this.currentPage = 1;
> > > >
> > > > which is totally against the OO style of ASP.NET.
> > > >
> > > > So my question is, how would you guys solve such a problem neatly?
> > > >
> > >
> > >
> > >[/color][/color]
>
>
>[/color]

re: How to avoid lifecycle hacks?

I didn't have time to fully digest your exact scenario but I have certainly
found problems in some pages regarding the order of firing events,
especially with user controls in the page.

One solution I have used on several occasions is have all the postback type
events (button clicks etc) just set instance variables to indicate what was
happening, then leave all the real work until the pre-render method.

Andy

re: How to avoid lifecycle hacks?

Hi Homam,

I don't see how firing a js function to set a flag that notifies the server
that the criteria has changed causes any problems. Especially once you
encapsulate this functionality into a custom control and simply drop it on
any page you need it. As you know the page load event will always fire
before the button click. Without using any type of smart-client
functionality all your work needs to be done on the server. The only way to
do this is to maintain state. You can do that with the Session object. In
your page load, compare the new criteria to the old criteria. If it doesn't
match then you know what you need to do. However once your pages become
more complicated, specifically post backs can be made from actions other
than the submit button click, you may find that simply having the client
tell you what they need instead of making the server figure it out, is the
way to go. Good luck! I hope more people can join this conversation and
help put together the right solution for you. Ken.

--
Ken Dopierala Jr.
For great ASP.Net web hosting try:
http://www.webhost4life.com/default.asp?refid=Spinlight
If you sign up under me and need help, email me.

"Homam" <Homam@discussions.microsoft.com> wrote in message
news:05F9E38A-31BB-4CB4-BD93-0E08AD5E30EA@microsoft.com...[color=blue]
> Hi Ken,
>
> Using JavaScript and hidden form fields is pretty much the same hack as
> checking whether the SubmitButton exists in the form object. I'm just[/color]
trying[color=blue]
> to figure out a solution along the line of ASP.NET's event-driven, OO[/color]
model.[color=blue]
>
> Thanks,
>
> Homam
>
>
>
>
> "Ken Dopierala Jr." wrote:
>[color=green]
> > Hi,
> >
> > I think implementing a Master Pages type scenario is what you are[/color][/color]
looking[color=blue][color=green]
> > for. They are built into v2.0 of the framework but here are some link[/color][/color]
for[color=blue][color=green]
> > implementing them in v1.1:
> >
> > http://www.codeproject.com/aspnet/PageFramework.asp
> >
> > http://www.codeproject.com/aspnet/Frame_Work_Design.asp
> >
> > Also read through this from Microsoft's Patterns & Practices:
> >
> >[/color][/color]
http://msdn.microsoft.com/library/de...tml/DesMVC.asp[color=blue][color=green]
> >
> > For your paging navigation I would recommend creating your own custom
> > control with all UI necessary to page (i.e. page selection links or
> > dropdown, submit button, previous/next links). This will allow you to[/color][/color]
make[color=blue][color=green]
> > it very generic and at the same time expose a number of custom[/color][/color]
properties[color=blue][color=green]
> > that can be changed in the property window of the IDE to customize for[/color][/color]
any[color=blue][color=green]
> > scenario. For example in one scenario you may show the current page and
> > links to the two pages behind or ahead of it. Where as in another[/color][/color]
scenario[color=blue][color=green]
> > you may show the page you are on, the immediate pages around it and[/color][/color]
links to[color=blue][color=green]
> > also go all the way to the beginning or end of the data. In your custom
> > control include the javascript necessary to set a hidden input to the
> > correct page when the submit button is clicked. Then have your base[/color][/color]
page[color=blue][color=green]
> > check this hidden input before loading the data. Now you'll know where[/color][/color]
to[color=blue][color=green]
> > go before the submit button click even fires. In fact, you wouldn't[/color][/color]
even[color=blue][color=green]
> > need to capture the click event on the server-side. Good luck! Ken.
> >
> > --
> > Ken Dopierala Jr.
> > For great ASP.Net web hosting try:
> > http://www.webhost4life.com/default.asp?refid=Spinlight
> > If you sign up under me and need help, email me.
> >
> > "Homam" <Homam@discussions.microsoft.com> wrote in message
> > news:C138BFAD-0487-42A5-B762-A91F16E76DA8@microsoft.com...[color=darkred]
> > > Hi Ken,
> > >
> > > This wouldn't slove my problem because even when I add an intermediate
> > > class, the overloaded Load event will still fire before the[/color][/color][/color]
SubmitButton's[color=blue][color=green][color=darkred]
> > > Click event. So if the user clicked on that button to update the[/color][/color][/color]
criteria,[color=blue][color=green][color=darkred]
> > > the current page will be set AFTER the query has already executed, and[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > ResultSetDisplay will display the wrong page.
> > >
> > > To illustrate, let's say that the user submitted a set of criteria C1[/color][/color][/color]
and[color=blue][color=green][color=darkred]
> > > browsed to page number 5 of the its result set. Then he changed the[/color]
> > criteria[color=darkred]
> > > to C2 and hit the SubmitButton. Now if I execute the query in the[/color]
> > overloaded[color=darkred]
> > > Load event handler in the derived class, the query will retrieve page[/color][/color][/color]
5 of[color=blue][color=green][color=darkred]
> > > C2, not page 1 as it should, because the page was set in the[/color][/color][/color]
SubmitButton[color=blue][color=green][color=darkred]
> > > event handler after the query got executed.
> > >
> > > By the way, the code is executed in the Code Behind class, which is[/color]
> > derived[color=darkred]
> > > from Page anyway.
> > >
> > > I'm very well versed in OOA/D/P and all the design patterns[/color][/color][/color]
paraphernalia[color=blue][color=green]
> > (I[color=darkred]
> > > come from a J2EE background), but I'm still trying to figure out[/color][/color][/color]
ASP.NET's[color=blue][color=green][color=darkred]
> > > plumbing.
> > >
> > > Thanks for your feedback.
> > >
> > >
> > >
> > >
> > > "Ken Dopierala Jr." wrote:
> > >
> > > > Hi,
> > > >
> > > > I would create a base page class and derive my pages from this[/color][/color][/color]
class.[color=blue][color=green]
> > The[color=darkred]
> > > > base page's Page_Load event will fire first, you can then hit your[/color][/color][/color]
data[color=blue][color=green][color=darkred]
> > > > access and business logic layers here. Retrieving the data you need[/color][/color][/color]
and[color=blue][color=green][color=darkred]
> > > > setting custom properties for derived classes to check before they[/color]
> > render.[color=darkred]
> > > >
> > > > I would also recommend buying some books on OOP and studying them[/color]
> > carefully.[color=darkred]
> > > > You attempted to solve your problem using an almost top-down[/color][/color][/color]
approach.[color=blue][color=green]
> > When[color=darkred]
> > > > you are trying to implement an OO design you know you are on the[/color][/color][/color]
wrong[color=blue][color=green]
> > path[color=darkred]
> > > > when you try to rig things up after the fact. Always try to think[/color][/color][/color]
what[color=blue][color=green][color=darkred]
> > > > would come first. In this case a base class will solve your problem[/color][/color][/color]
and[color=blue][color=green][color=darkred]
> > > > also make your code much more elegant and extensible. Good luck![/color][/color][/color]
Ken.[color=blue][color=green][color=darkred]
> > > >
> > > > --
> > > > Ken Dopierala Jr.
> > > > For great ASP.Net web hosting try:
> > > > http://www.webhost4life.com/default.asp?refid=Spinlight
> > > > If you sign up under me and need help, email me.
> > > >
> > > > "Homam" <Homam@discussions.microsoft.com> wrote in message
> > > > news:A2C2B1CE-90B5-4D49-9FCF-0D9B8733CDC0@microsoft.com...
> > > > > The ASP.NET model is touted as a clean OO approach to developing[/color][/color][/color]
web[color=blue][color=green][color=darkred]
> > > > pages,
> > > > > yet sometimes the page lifecycle poses silly obstacles that forces[/color][/color][/color]
you[color=blue][color=green][color=darkred]
> > > > revert
> > > > > to the Olde ASP 3.0 Ways.
> > > > >
> > > > > Here's a rough outline of an ASPX page:
> > > > >
> > > > > ... a bunch of criteria controls...
> > > > > PagingNav
> > > > > ResultSetDisplay
> > > > > SubmitButton
> > > > >
> > > > > Basically, the PagingNav allows the user to navigate through the[/color][/color][/color]
DB[color=blue][color=green]
> > result[color=darkred]
> > > > > set; the ResultSetDisplay shows the currently selected page in a[/color][/color][/color]
data[color=blue][color=green][color=darkred]
> > > > list;
> > > > > and the SubmitButton is used in case the user changed criteria and[/color]
> > wants[color=darkred]
> > > > to
> > > > > update the view.
> > > > >
> > > > > Now, the PagingNav control needs to know the total number of[/color][/color][/color]
records[color=blue][color=green]
> > found[color=darkred]
> > > > > in the DB, so the query must be exectued before it's rendered.[/color]
> > Therefore I[color=darkred]
> > > > > have to execute the query before the PreRender event of PagingNav,[/color]
> > which[color=darkred]
> > > > > means I cannot, for example, execute the query in the PreRender[/color][/color][/color]
event[color=blue][color=green]
> > of[color=darkred]
> > > > the
> > > > > ResultSetDisplay control since it will be executed after the[/color][/color][/color]
PreRender[color=blue][color=green][color=darkred]
> > > > event
> > > > > of the PagingNav control (due to its position in the page). In[/color][/color][/color]
other[color=blue][color=green][color=darkred]
> > > > words,
> > > > > it would be too late for the PageNavControl to figure out the[/color][/color][/color]
total[color=blue][color=green][color=darkred]
> > > > records
> > > > > the query found. I can execute the query in any event of[/color]
> > ResultSetDisplay[color=darkred]
> > > > > that fires before PreRender. So far so good.
> > > > >
> > > > > Enter the SubmitButton control, which messes up the whole plan.[/color][/color][/color]
The[color=blue][color=green][color=darkred]
> > > > problem
> > > > > is, I want to reset the current page number to 1 whenever this[/color][/color][/color]
button[color=blue][color=green]
> > is[color=darkred]
> > > > > clicked. So I add code to do that in its SubmitButton_Click. Alas,[/color]
> > this[color=darkred]
> > > > event
> > > > > executes AFTER the Load event of the ResultSetDisplay and BEFORE[/color][/color][/color]
its[color=blue][color=green][color=darkred]
> > > > > PreRender event. This means to get the ResultSetDisplay to dispay[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > > > appropriate page (i.e. # 1), I have to excute the query in an[/color][/color][/color]
event[color=blue][color=green]
> > that[color=darkred]
> > > > > takes place after the SubmitButton_Click event, which is the[/color][/color][/color]
PreRender[color=blue][color=green][color=darkred]
> > > > event.
> > > > > But that pretty much screws up the PagingNav control since, as[/color]
> > explained[color=darkred]
> > > > > above, it needs to find out how many records the query found, but[/color][/color][/color]
it's[color=blue][color=green]
> > too[color=darkred]
> > > > > late now.
> > > > >
> > > > > So, to fix the problem, I have to revert to ASP 3.0 hacks and add
> > > > something
> > > > > in the Load event of the ResultSetDispay such as:
> > > > >
> > > > > if (Request.Form["update"] != null)
> > > > > this.currentPage = 1;
> > > > >
> > > > > which is totally against the OO style of ASP.NET.
> > > > >
> > > > > So my question is, how would you guys solve such a problem neatly?
> > > > >
> > > >
> > > >
> > > >[/color]
> >
> >
> >[/color][/color]

re: How to avoid lifecycle hacks?

On Wed, 2 Mar 2005 21:59:01 -0800, "Homam"
<Homam@discussions.microsoft.com> wrote:
[color=blue]
>Hi Scott,
>
>Actually the code that retrieves the result set is factored as you
>indicated, and you're right, it's passed a page number. Currently I'm calling
>it from the Load event handler of the ResultSetDisplay.
>
>Your proposed solution (i.e. calling this function from either
>SubmitButton's Click event handler XOR the Load event handler) requires the
>same hack. That's because I have to call this function from the Load event
>while making sure the SubmitButton control wasn't clicked (so that I don't
>end up calling it twice, once in the Load event handler and once in the
>SubmitButton's Click event handler). And there's no way of knowing during the
>execution of the Load event handler if the SubmitButton was clicked other
>than that hack that I mentioned in my original message. IsPostBack won't cut
>it here because other controls could also submit the page (e.g. the
>PagingNav), not just the SubmitButton.
>[/color]

Think of this way - if IsPostBack is true, one of the other controls
raised a postback event, so do not do any queries or data binding from
page load. Do the data binding from an event handler for the postback,
be it the submit button or the nav controls.

--
Scott
http://www.OdeToCode.com/blogs/scott/

re: How to avoid lifecycle hacks?

Scott,

Calling the he function from all the post event handlers (SubmitButton,
PagingNav, etc) and from the page's Load event handler if it's not IsPostBack
works pretty well!

Thanks for your help,

Homam



"Scott Allen" wrote:
[color=blue]
> On Wed, 2 Mar 2005 21:59:01 -0800, "Homam"
> <Homam@discussions.microsoft.com> wrote:
>[color=green]
> >Hi Scott,
> >
> >Actually the code that retrieves the result set is factored as you
> >indicated, and you're right, it's passed a page number. Currently I'm calling
> >it from the Load event handler of the ResultSetDisplay.
> >
> >Your proposed solution (i.e. calling this function from either
> >SubmitButton's Click event handler XOR the Load event handler) requires the
> >same hack. That's because I have to call this function from the Load event
> >while making sure the SubmitButton control wasn't clicked (so that I don't
> >end up calling it twice, once in the Load event handler and once in the
> >SubmitButton's Click event handler). And there's no way of knowing during the
> >execution of the Load event handler if the SubmitButton was clicked other
> >than that hack that I mentioned in my original message. IsPostBack won't cut
> >it here because other controls could also submit the page (e.g. the
> >PagingNav), not just the SubmitButton.
> >[/color]
>
> Think of this way - if IsPostBack is true, one of the other controls
> raised a postback event, so do not do any queries or data binding from
> page load. Do the data binding from an event handler for the postback,
> be it the submit button or the nav controls.
>
> --
> Scott
> http://www.OdeToCode.com/blogs/scott/
>
>[/color]

re: How to avoid lifecycle hacks?

Thanks, Ken, for the tips.

Scott Allen solved my problem (factor out code, call it from all postback
handlers, in addition to load handler if IsPostBack is false).

But you're right, taking advantage of ASP.NET custom controls and
client-side script event postbacks (e.g. the Page classes methods) is another
long-term solution to it.

Homam




"Ken Dopierala Jr." wrote:
[color=blue]
> Hi Homam,
>
> I don't see how firing a js function to set a flag that notifies the server
> that the criteria has changed causes any problems. Especially once you
> encapsulate this functionality into a custom control and simply drop it on
> any page you need it. As you know the page load event will always fire
> before the button click. Without using any type of smart-client
> functionality all your work needs to be done on the server. The only way to
> do this is to maintain state. You can do that with the Session object. In
> your page load, compare the new criteria to the old criteria. If it doesn't
> match then you know what you need to do. However once your pages become
> more complicated, specifically post backs can be made from actions other
> than the submit button click, you may find that simply having the client
> tell you what they need instead of making the server figure it out, is the
> way to go. Good luck! I hope more people can join this conversation and
> help put together the right solution for you. Ken.
>
> --
> Ken Dopierala Jr.
> For great ASP.Net web hosting try:
> http://www.webhost4life.com/default.asp?refid=Spinlight
> If you sign up under me and need help, email me.
>
> "Homam" <Homam@discussions.microsoft.com> wrote in message
> news:05F9E38A-31BB-4CB4-BD93-0E08AD5E30EA@microsoft.com...[color=green]
> > Hi Ken,
> >
> > Using JavaScript and hidden form fields is pretty much the same hack as
> > checking whether the SubmitButton exists in the form object. I'm just[/color]
> trying[color=green]
> > to figure out a solution along the line of ASP.NET's event-driven, OO[/color]
> model.[color=green]
> >
> > Thanks,
> >
> > Homam
> >
> >
> >
> >
> > "Ken Dopierala Jr." wrote:
> >[color=darkred]
> > > Hi,
> > >
> > > I think implementing a Master Pages type scenario is what you are[/color][/color]
> looking[color=green][color=darkred]
> > > for. They are built into v2.0 of the framework but here are some link[/color][/color]
> for[color=green][color=darkred]
> > > implementing them in v1.1:
> > >
> > > http://www.codeproject.com/aspnet/PageFramework.asp
> > >
> > > http://www.codeproject.com/aspnet/Frame_Work_Design.asp
> > >
> > > Also read through this from Microsoft's Patterns & Practices:
> > >
> > >[/color][/color]
> http://msdn.microsoft.com/library/de...tml/DesMVC.asp[color=green][color=darkred]
> > >
> > > For your paging navigation I would recommend creating your own custom
> > > control with all UI necessary to page (i.e. page selection links or
> > > dropdown, submit button, previous/next links). This will allow you to[/color][/color]
> make[color=green][color=darkred]
> > > it very generic and at the same time expose a number of custom[/color][/color]
> properties[color=green][color=darkred]
> > > that can be changed in the property window of the IDE to customize for[/color][/color]
> any[color=green][color=darkred]
> > > scenario. For example in one scenario you may show the current page and
> > > links to the two pages behind or ahead of it. Where as in another[/color][/color]
> scenario[color=green][color=darkred]
> > > you may show the page you are on, the immediate pages around it and[/color][/color]
> links to[color=green][color=darkred]
> > > also go all the way to the beginning or end of the data. In your custom
> > > control include the javascript necessary to set a hidden input to the
> > > correct page when the submit button is clicked. Then have your base[/color][/color]
> page[color=green][color=darkred]
> > > check this hidden input before loading the data. Now you'll know where[/color][/color]
> to[color=green][color=darkred]
> > > go before the submit button click even fires. In fact, you wouldn't[/color][/color]
> even[color=green][color=darkred]
> > > need to capture the click event on the server-side. Good luck! Ken.
> > >
> > > --
> > > Ken Dopierala Jr.
> > > For great ASP.Net web hosting try:
> > > http://www.webhost4life.com/default.asp?refid=Spinlight
> > > If you sign up under me and need help, email me.
> > >
> > > "Homam" <Homam@discussions.microsoft.com> wrote in message
> > > news:C138BFAD-0487-42A5-B762-A91F16E76DA8@microsoft.com...
> > > > Hi Ken,
> > > >
> > > > This wouldn't slove my problem because even when I add an intermediate
> > > > class, the overloaded Load event will still fire before the[/color][/color]
> SubmitButton's[color=green][color=darkred]
> > > > Click event. So if the user clicked on that button to update the[/color][/color]
> criteria,[color=green][color=darkred]
> > > > the current page will be set AFTER the query has already executed, and[/color][/color]
> the[color=green][color=darkred]
> > > > ResultSetDisplay will display the wrong page.
> > > >
> > > > To illustrate, let's say that the user submitted a set of criteria C1[/color][/color]
> and[color=green][color=darkred]
> > > > browsed to page number 5 of the its result set. Then he changed the
> > > criteria
> > > > to C2 and hit the SubmitButton. Now if I execute the query in the
> > > overloaded
> > > > Load event handler in the derived class, the query will retrieve page[/color][/color]
> 5 of[color=green][color=darkred]
> > > > C2, not page 1 as it should, because the page was set in the[/color][/color]
> SubmitButton[color=green][color=darkred]
> > > > event handler after the query got executed.
> > > >
> > > > By the way, the code is executed in the Code Behind class, which is
> > > derived
> > > > from Page anyway.
> > > >
> > > > I'm very well versed in OOA/D/P and all the design patterns[/color][/color]
> paraphernalia[color=green][color=darkred]
> > > (I
> > > > come from a J2EE background), but I'm still trying to figure out[/color][/color]
> ASP.NET's[color=green][color=darkred]
> > > > plumbing.
> > > >
> > > > Thanks for your feedback.
> > > >
> > > >
> > > >
> > > >
> > > > "Ken Dopierala Jr." wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I would create a base page class and derive my pages from this[/color][/color]
> class.[color=green][color=darkred]
> > > The
> > > > > base page's Page_Load event will fire first, you can then hit your[/color][/color]
> data[color=green][color=darkred]
> > > > > access and business logic layers here. Retrieving the data you need[/color][/color]
> and[color=green][color=darkred]
> > > > > setting custom properties for derived classes to check before they
> > > render.
> > > > >
> > > > > I would also recommend buying some books on OOP and studying them
> > > carefully.
> > > > > You attempted to solve your problem using an almost top-down[/color][/color]
> approach.[color=green][color=darkred]
> > > When
> > > > > you are trying to implement an OO design you know you are on the[/color][/color]
> wrong[color=green][color=darkred]
> > > path
> > > > > when you try to rig things up after the fact. Always try to think[/color][/color]
> what[color=green][color=darkred]
> > > > > would come first. In this case a base class will solve your problem[/color][/color]
> and[color=green][color=darkred]
> > > > > also make your code much more elegant and extensible. Good luck![/color][/color]
> Ken.[color=green][color=darkred]
> > > > >
> > > > > --
> > > > > Ken Dopierala Jr.
> > > > > For great ASP.Net web hosting try:
> > > > > http://www.webhost4life.com/default.asp?refid=Spinlight
> > > > > If you sign up under me and need help, email me.
> > > > >
> > > > > "Homam" <Homam@discussions.microsoft.com> wrote in message
> > > > > news:A2C2B1CE-90B5-4D49-9FCF-0D9B8733CDC0@microsoft.com...
> > > > > > The ASP.NET model is touted as a clean OO approach to developing[/color][/color]
> web[color=green][color=darkred]
> > > > > pages,
> > > > > > yet sometimes the page lifecycle poses silly obstacles that forces[/color][/color]
> you[color=green][color=darkred]
> > > > > revert
> > > > > > to the Olde ASP 3.0 Ways.
> > > > > >
> > > > > > Here's a rough outline of an ASPX page:
> > > > > >
> > > > > > ... a bunch of criteria controls...
> > > > > > PagingNav
> > > > > > ResultSetDisplay
> > > > > > SubmitButton
> > > > > >
> > > > > > Basically, the PagingNav allows the user to navigate through the[/color][/color]
> DB[color=green][color=darkred]
> > > result
> > > > > > set; the ResultSetDisplay shows the currently selected page in a[/color][/color]
> data[color=green][color=darkred]
> > > > > list;
> > > > > > and the SubmitButton is used in case the user changed criteria and
> > > wants
> > > > > to
> > > > > > update the view.
> > > > > >
> > > > > > Now, the PagingNav control needs to know the total number of[/color][/color]
> records[color=green][color=darkred]
> > > found
> > > > > > in the DB, so the query must be exectued before it's rendered.
> > > Therefore I
> > > > > > have to execute the query before the PreRender event of PagingNav,
> > > which
> > > > > > means I cannot, for example, execute the query in the PreRender[/color][/color]
> event[color=green][color=darkred]
> > > of
> > > > > the
> > > > > > ResultSetDisplay control since it will be executed after the[/color][/color]
> PreRender[color=green][color=darkred]
> > > > > event
> > > > > > of the PagingNav control (due to its position in the page). In[/color][/color]
> other[color=green][color=darkred]
> > > > > words,
> > > > > > it would be too late for the PageNavControl to figure out the[/color][/color]
> total[color=green][color=darkred]
> > > > > records
> > > > > > the query found. I can execute the query in any event of
> > > ResultSetDisplay
> > > > > > that fires before PreRender. So far so good.
> > > > > >
> > > > > > Enter the SubmitButton control, which messes up the whole plan.[/color][/color]
> The[color=green][color=darkred]
> > > > > problem
> > > > > > is, I want to reset the current page number to 1 whenever this[/color][/color]
> button[color=green][color=darkred]
> > > is
> > > > > > clicked. So I add code to do that in its SubmitButton_Click. Alas,
> > > this
> > > > > event
> > > > > > executes AFTER the Load event of the ResultSetDisplay and BEFORE[/color][/color]
> its[color=green][color=darkred]
> > > > > > PreRender event. This means to get the ResultSetDisplay to dispay[/color][/color]
> the[color=green][color=darkred]
> > > > > > appropriate page (i.e. # 1), I have to excute the query in an[/color][/color]
> event[color=green][color=darkred]
> > > that
> > > > > > takes place after the SubmitButton_Click event, which is the[/color][/color]
> PreRender[color=green][color=darkred]
> > > > > event.
> > > > > > But that pretty much screws up the PagingNav control since, as
> > > explained
> > > > > > above, it needs to find out how many records the query found, but[/color][/color]
> it's[color=green][color=darkred]
> > > too
> > > > > > late now.
> > > > > >
> > > > > > So, to fix the problem, I have to revert to ASP 3.0 hacks and add
> > > > > something
> > > > > > in the Load event of the ResultSetDispay such as:
> > > > > >
> > > > > > if (Request.Form["update"] != null)
> > > > > > this.currentPage = 1;
> > > > > >
> > > > > > which is totally against the OO style of ASP.NET.
> > > > > >
> > > > > > So my question is, how would you guys solve such a problem neatly?
> > > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >[/color][/color]
>
>
>[/color]