You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Ralph Churchill <mr...@yahoo.com> on 2004/04/28 18:30:30 UTC
database-driven PropertySelection
I'm using a PropertySelection component that is
populated from a database depending on a particular
value. So, the contents of the PropertySelection will
can vary.
I'm also using onSubmit="true" to change other
information on the page. My question is this: what is
a good way to load the PropertySelection the "first"
time the user visits the page, so that every time the
page is reloaded (i.e. the PropertySelcetion changes
and the form is submitted) the database does not need
to be queried? I tried using a member variable, like
so:
private IPropertySelection options;
IPropertySelection getOptions()
{
if(options == null) {
options= new MyPropertySelectionModel(
QueryDatabaseForOptions(getValue()));
// where getValue() returns the "value"
// from the Visit which was set on
// an earlier page
}
return options;
}
That works fine... until the user leaves the page,
picks a different "value", then returns to the page
with the PropertySelection... I tried clearing the
PropertySelection model on "detach()", but obviously,
that defeats the purpose of caching since the form
gets resubmitted constantly.
I assume something like this is pretty common...
what's a Best Practice?
RMC
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: database-driven PropertySelection
Posted by Jamie Orchard-Hays <ja...@dang.com>.
The problem with this technique is that the calling page has to know to do
this. With my way and Ralph's way, other pages don't have to do anything
special.
----- Original Message -----
From: "John Studarus" <st...@jhlconsulting.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Wednesday, April 28, 2004 2:21 PM
Subject: Re: database-driven PropertySelection
>
> Have the calling page set the called page attribute.
> So, if page A calls (activates) page B (which contains
> the PropertySelection). Then store the model persistently
> so on reloads it does not get changed. I do this
> all the time and it works well.
>
> John
>
>
> On Wed, Apr 28, 2004 at 09:30:30AM -0700, Ralph Churchill wrote:
> > I'm using a PropertySelection component that is
> > populated from a database depending on a particular
> > value. So, the contents of the PropertySelection will
> > can vary.
> >
> > I'm also using onSubmit="true" to change other
> > information on the page. My question is this: what is
> > a good way to load the PropertySelection the "first"
> > time the user visits the page, so that every time the
> > page is reloaded (i.e. the PropertySelcetion changes
> > and the form is submitted) the database does not need
> > to be queried? I tried using a member variable, like
> > so:
> >
> > private IPropertySelection options;
> >
> > IPropertySelection getOptions()
> > {
> > if(options == null) {
> > options= new MyPropertySelectionModel(
> > QueryDatabaseForOptions(getValue()));
> > // where getValue() returns the "value"
> > // from the Visit which was set on
> > // an earlier page
> > }
> > return options;
> > }
> >
> > That works fine... until the user leaves the page,
> > picks a different "value", then returns to the page
> > with the PropertySelection... I tried clearing the
> > PropertySelection model on "detach()", but obviously,
> > that defeats the purpose of caching since the form
> > gets resubmitted constantly.
> >
> > I assume something like this is pretty common...
> > what's a Best Practice?
> >
> > RMC
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Win a $20,000 Career Makeover at Yahoo! HotJobs
> > http://hotjobs.sweepstakes.yahoo.com/careermakeover
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: database-driven PropertySelection
Posted by John Studarus <st...@jhlconsulting.com>.
Have the calling page set the called page attribute.
So, if page A calls (activates) page B (which contains
the PropertySelection). Then store the model persistently
so on reloads it does not get changed. I do this
all the time and it works well.
John
On Wed, Apr 28, 2004 at 09:30:30AM -0700, Ralph Churchill wrote:
> I'm using a PropertySelection component that is
> populated from a database depending on a particular
> value. So, the contents of the PropertySelection will
> can vary.
>
> I'm also using onSubmit="true" to change other
> information on the page. My question is this: what is
> a good way to load the PropertySelection the "first"
> time the user visits the page, so that every time the
> page is reloaded (i.e. the PropertySelcetion changes
> and the form is submitted) the database does not need
> to be queried? I tried using a member variable, like
> so:
>
> private IPropertySelection options;
>
> IPropertySelection getOptions()
> {
> if(options == null) {
> options= new MyPropertySelectionModel(
> QueryDatabaseForOptions(getValue()));
> // where getValue() returns the "value"
> // from the Visit which was set on
> // an earlier page
> }
> return options;
> }
>
> That works fine... until the user leaves the page,
> picks a different "value", then returns to the page
> with the PropertySelection... I tried clearing the
> PropertySelection model on "detach()", but obviously,
> that defeats the purpose of caching since the form
> gets resubmitted constantly.
>
> I assume something like this is pretty common...
> what's a Best Practice?
>
> RMC
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Win a $20,000 Career Makeover at Yahoo! HotJobs
> http://hotjobs.sweepstakes.yahoo.com/careermakeover
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: database-driven PropertySelection
Posted by Ralph Churchill <mr...@yahoo.com>.
I think I can accomplish this by storing the "value"
as a member variable and then checking if what's in
the Visit and what's in the class are different... If
so, reinitialize. Like you said, a bit of a pain...
but better than hitting the database every time.
I'm still entertaining suggestions, though :)
RMC
--- Jamie Orchard-Hays <ja...@dang.com> wrote:
> You're right. I missed the part about needing to
> reinitialize when the data
> changes.
>
> What I've done on for this sort of situation is put
> a boolean in our base
> page called resetForms. I wanted to have some
> persistent properties on
> forms, but wanted them reset when the user wandered
> off and came back (ie,
> for situations like they cancelled the form without
> using the cancel
> button--by just navigation somewhere else) or
> clicked a menu item to go to
> the a. By default, resetForms is true, but when the
> forms are being used, I
> just call setResetForm(false) during the form rewind
> phase. A little bit of
> a pain, but not much.
>
> Jamie
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: database-driven PropertySelection
Posted by Jamie Orchard-Hays <ja...@dang.com>.
You're right. I missed the part about needing to reinitialize when the data
changes.
What I've done on for this sort of situation is put a boolean in our base
page called resetForms. I wanted to have some persistent properties on
forms, but wanted them reset when the user wandered off and came back (ie,
for situations like they cancelled the form without using the cancel
button--by just navigation somewhere else) or clicked a menu item to go to
the a. By default, resetForms is true, but when the forms are being used, I
just call setResetForm(false) during the form rewind phase. A little bit of
a pain, but not much.
Jamie
----- Original Message -----
From: "Ralph Churchill" <mr...@yahoo.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Wednesday, April 28, 2004 12:48 PM
Subject: Re: database-driven PropertySelection
> But, wouldn't that just get me right back to where I
> was? Because the pageBeginRender will be called
> repeatedly when I submit the form... so I'll need to
> check if it was already initialized. Which it would be
> because it was persisted. But, then, if I come back to
> the page after having changed the "value" on an
> earlier page... then my check to see if the list was
> already initialized would succeed... but have the
> wrong data. Is my understanding of "check if
> initialized" wrong?
>
> public void pageBeginRender(PageEvent event)
> {
> // check if it exists, if not init
> if(getPropertySelectionModel() == null) {
> IPropertySelectionModel p =
> new MyPropertySelectionModel(
> QueryDatabaseForOptions(getValue()));
> setPropertySelectionModel(p);
> }
>
> RMC
> --- Jamie Orchard-Hays <ja...@dang.com> wrote:
> > One way is to define options in the .page file and
> > use abstract get/set in
> > the java file. Make options persistent="yes". Then,
> > in your
> > pageBeginRender() you can initialize it. The
> > disadvantage of this is that
> > your options is persisted the no matter what pages
> > the user wanders off
> > to--but this sounds like what you want.
> >
> > Jamie
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Win a $20,000 Career Makeover at Yahoo! HotJobs
> http://hotjobs.sweepstakes.yahoo.com/careermakeover
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: database-driven PropertySelection
Posted by Ralph Churchill <mr...@yahoo.com>.
But, wouldn't that just get me right back to where I
was? Because the pageBeginRender will be called
repeatedly when I submit the form... so I'll need to
check if it was already initialized. Which it would be
because it was persisted. But, then, if I come back to
the page after having changed the "value" on an
earlier page... then my check to see if the list was
already initialized would succeed... but have the
wrong data. Is my understanding of "check if
initialized" wrong?
public void pageBeginRender(PageEvent event)
{
// check if it exists, if not init
if(getPropertySelectionModel() == null) {
IPropertySelectionModel p =
new MyPropertySelectionModel(
QueryDatabaseForOptions(getValue()));
setPropertySelectionModel(p);
}
RMC
--- Jamie Orchard-Hays <ja...@dang.com> wrote:
> One way is to define options in the .page file and
> use abstract get/set in
> the java file. Make options persistent="yes". Then,
> in your
> pageBeginRender() you can initialize it. The
> disadvantage of this is that
> your options is persisted the no matter what pages
> the user wanders off
> to--but this sounds like what you want.
>
> Jamie
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: database-driven PropertySelection
Posted by Jamie Orchard-Hays <ja...@dang.com>.
One way is to define options in the .page file and use abstract get/set in
the java file. Make options persistent="yes". Then, in your
pageBeginRender() you can initialize it. The disadvantage of this is that
your options is persisted the no matter what pages the user wanders off
to--but this sounds like what you want.
Jamie
----- Original Message -----
From: "Ralph Churchill" <mr...@yahoo.com>
To: <ta...@jakarta.apache.org>
Sent: Wednesday, April 28, 2004 12:30 PM
Subject: database-driven PropertySelection
> I'm using a PropertySelection component that is
> populated from a database depending on a particular
> value. So, the contents of the PropertySelection will
> can vary.
>
> I'm also using onSubmit="true" to change other
> information on the page. My question is this: what is
> a good way to load the PropertySelection the "first"
> time the user visits the page, so that every time the
> page is reloaded (i.e. the PropertySelcetion changes
> and the form is submitted) the database does not need
> to be queried? I tried using a member variable, like
> so:
>
> private IPropertySelection options;
>
> IPropertySelection getOptions()
> {
> if(options == null) {
> options= new MyPropertySelectionModel(
> QueryDatabaseForOptions(getValue()));
> // where getValue() returns the "value"
> // from the Visit which was set on
> // an earlier page
> }
> return options;
> }
>
> That works fine... until the user leaves the page,
> picks a different "value", then returns to the page
> with the PropertySelection... I tried clearing the
> PropertySelection model on "detach()", but obviously,
> that defeats the purpose of caching since the form
> gets resubmitted constantly.
>
> I assume something like this is pretty common...
> what's a Best Practice?
>
> RMC
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Win a $20,000 Career Makeover at Yahoo! HotJobs
> http://hotjobs.sweepstakes.yahoo.com/careermakeover
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org