You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by J <ja...@yahoo.com> on 2004/12/19 05:15:23 UTC
Newbie Q: Lists and persistent property
Hello All,
I have a simple list working following the tapestry in
action pp120-132. The thing I'm confused about
though, is if I remove the persistent property of the
list then I start getting stale link errors.
Q: I'm wondering why the list doesn't work the same as
the more simple fields without the persistence?
For example, the simple text entry fields keep their
state OK when posting back. When I remove the
persistent property of the list the first post back
works and adds an item, but all subsequent post backs
result in the stale link error.
Jason
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Newbie Q: Lists and persistent property
Posted by Bryan Lewis <br...@maine.rr.com>.
Silly me. The reason I was getting the StaleLink exception after the
discarding was that my list page was using ActionLinks. I changed them to
DirectLinks, passing the object's primary key, and back-buttoning works
again.
----- Original Message -----
From: "Bryan Lewis" <br...@maine.rr.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Thursday, December 23, 2004 12:48 PM
Subject: Re: Newbie Q: Lists and persistent property
> Well, I hadn't actually tried the idea, but it ought to work. I've had no
> trouble getting to my custom Engine class from my border component, by
> calling the enclosing page rather than the RequestCycle like: MyEngine
> engine = (MyEngine) getPage().getEngine().
> I don't know why cycle.getEngine() isn't working for you. It doesn't seem
> right that a simple casting would cause you to get a null return value...
> there might be something else wrong.
>
> Anyway, enough hypothesizing. I tried implementing the idea. In my
Engine
> class I added:
>
> public void discardActivePages(IRequestCycle cycle)
> {
> Collection pageNames = getActivePageNames();
> for (Iterator it = pageNames.iterator(); it.hasNext(); ) {
> String pageName = (String) it.next();
> try {
> log.debug("Discarding page " + pageName);
> cycle.discardPage(pageName);
> }
> catch (Exception ex) {
> log.debug("Couldn't discard page " + pageName + ", got
> exception: "
> + ex.getClass().getName() + "; " +
ex.getMessage());
> }
> }
> }
>
> Notice that I renamed it to "discard" rather than "forget". I tried the
> forgetPage() technique first but after some stress-testing I got a
> java.util.ConcurrentModificationException, so I switched to
> cycle.discardPage() as recommended in the wiki page. My menu component
> does:
>
> public void menuItemClicked(IRequestCycle cycle)
> {
> String nextPageName = getMenuItem().getPage();
>
> log.debug("About to activate " + nextPageName + "page; discarding
> old pages first.");
> ((Engine) getPage().getEngine()).discardActivePages(cycle);
>
> // Get the next page and activate it as usual....
> }
>
> This works fine for me so far, but I can think of two disclaimers. I
> haven't load-tested it to see whether it's actually improving the
> performance. And it aggravates the back-button problem... if one is so
> foolish as to allow users to back-button to a previous page and click on a
> link. I have a large list page (no form, just a long list of links, maybe
a
> few hundred) that users must be able to go back to and reclick. It was
> working before when the list was persistent. Now that the list has been
> discarded I get a StaleLink exception. At least we know that the
discarding
> is working!
>
> Now, maybe your users are less demanding and a StaleLink is what they
> deserve for backing up :-) but I'll have to make this a little less
> aggressive. I won't discard the old pages on _every_ menu click but only
> when activating one of our two or three large list pages. Our convention
> would be, "You can only be working with one large list at a time... as
soon
> as you go to another one, the old one will be forgotten." I think that'll
> satisfy the way our users work, and it'll still clean up our biggest
memory
> hogs. (I wouldn't be surprised, though, if we judge this to be not worth
> the effort. Maybe we should just buy more memory for the server. I'd be
> interested to hear if it actually helps your performance.)
>
>
> ----- Original Message -----
> From: "J" <ja...@yahoo.com>
> To: "Tapestry users" <ta...@jakarta.apache.org>
> Sent: Thursday, December 23, 2004 10:52 AM
> Subject: Re: Newbie Q: Lists and persistent property
>
>
> > Hi Bryan,
> >
> > I like your idea - tried to give it a try and ran into
> > problems. I tried implementing forgetAllActivePages()
> > in a subclass of the engine. The problem I have is
> > getting a handle to the subclass in the border
> > component:
> >
> > -IEngine engine = cycle.getEngine(); works just fine,
> > but this doesn't get to the subclass
> > -tried casting a la: BaseEngineSub engine =
> > (BaseEngineSub) cycle.getEngine();, but this comes
> > back with a null
> > -tried implementing the IPage i/f in the component and
> > using the getVisit() method like I saw in the vlib,
> > but Tapestry returns an error that the Component null
> > may not implement the IPage interface
> >
> > Did you get this to fly? If so, how are you getting a
> > handle to the subclassed engine in the border class?
> >
> > Jason
> >
> > --- Bryan Lewis <br...@maine.rr.com> wrote:
> >
> > > Doesn't sound too kludgy to me, given the current
> > > state of things. I was
> > > thinking about trying this kind of house-cleaning in
> > > my border's navigation
> > > menu. When users click on a menu link, it would
> > > signify they're done with
> > > whatever page they were on.
> > >
> > > Is it really necessary for each page to add itself
> > > to a vector in
> > > pageBeginRender()? I was hoping to avoid that by
> > > providing a method in the
> > > engine -- let's call it forgetAllActivePages() --
> > > that iterates through the
> > > collection of all remembered pages --
> > > engine.getActivePageNames() -- and
> > > calls forgetPage() on each one. Then it's only
> > > necessary that the menu code
> > > call engine.forgetAllActivePages(), which is one
> > > line of code in one place.
> > >
> > >
> > > ----- Original Message -----
> > > From: "J" <ja...@yahoo.com>
> > > To: "Tapestry users"
> > > <ta...@jakarta.apache.org>
> > > Sent: Monday, December 20, 2004 8:30 PM
> > > Subject: Re: Newbie Q: Lists and persistent property
> > >
> > >
> > > > Thanks Danny,
> > > >
> > > > That helped with one part of the problem.
> > > >
> > > > In case somebody else runs into this, here's what
> > > I
> > > > did for the other part of the problem: the page
> > > with
> > > > the persistent data is contained within a border
> > > > component that has a menu structure on the left
> > > > (modeled after the virtual lib). The user
> > > inserted a
> > > > few list items, then clicked on a link in the
> > > border
> > > > that triggered a listener in the border - not in
> > > the
> > > > contained page with the persistent state - so the
> > > > contained page is not forwarding to another page
> > > and
> > > > can not clean up after itself. Then they clicked
> > > back
> > > > to the page and the half composed list was still
> > > > there.
> > > >
> > > > ...perhaps this should be cast as a feature? ;-)
> > > >
> > > > Anyway, the user expected the list to be cleared.
> > > So
> > > > what I did feels a bit kludgy, but it worked:
> > > > -added a Vector called 'pagesToForget' to the
> > > visit
> > > > object
> > > > -In the page with the persistent data, in the
> > > > pageBeginRender method I get the visit and add the
> > > > page to the Vector with something like
> > > >
> > > ...getPagesToForget().add(getPage().getPageName());
> > > > -In the border, for each listener I grab the visit
> > > > object, iterate over the pagesToForget, and
> > > discard
> > > > any pages that were added
> > > >
> > > > It feels kludgy because another component (the
> > > border)
> > > > is cleaning up after the other pages with
> > > persistent
> > > > state, but it works. If anybody has a better way
> > > of
> > > > cleaning up pls let me know.
> > > >
> > > > Jason
> > > >
> > > > --- Danny Mandel <dm...@tolweb.org> wrote:
> > > >
> > > > > Hi Jason. Have a look at this wiki page:
> > > > >
> > > > >
> > > >
> > >
> > http://wiki.apache.org/jakarta-tapestry/ClearingPersistentProperties
> > > > >
> > > > > Hope that helps,
> > > > > Danny
> > > > >
> > > > > J wrote:
> > > > >
> > > > > >That makes sense, thank you.
> > > > > >
> > > > > >On a related note, I'm curious about the best
> > > way
> > > > > to
> > > > > >reset the persistent data in a menu driven app
> > > like
> > > > > >the virtual lib (I searched the vlib example
> > > and
> > > > > >couldn't see an answer to this Q).
> > > > > >
> > > > > >For example, I see how I can reset the data on
> > > a
> > > > > page
> > > > > >submit within the class before moving to
> > > another
> > > > > page
> > > > > >by doing a
> > > > > 'setItems(null);cycle.activate(nextPage);'
> > > > > >
> > > > > >However, what about if the user clicks on a
> > > menu
> > > > > >within the border component, then clicks back?
> > > The
> > > > > >simple fields are reset OK, but the persistent
> > > data
> > > > > is
> > > > > >not. The only alternative I see is to detect
> > > that
> > > > > it
> > > > > >is a 'new visit' to the page in the
> > > > > pageBeginRender()
> > > > > >method somehow and reset the list to null
> > > there.
> > > > > >
> > > > > >Q: is there a better way to reset the
> > > persistent
> > > > > data?
> > > > > >
> > > > > >Jason
> > > > > >
> > > > > >--- Jamie Orchard-Hays <ja...@dang.com> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >>The simple fields are being submitted with the
> > > > > form,
> > > > > >>so there is data
> > > > > >>for them available during the rewind. The list
> > > > > >>itself is not stored on
> > > > > >>or submitted by the web page, so that data
> > > needs
> > > > > to
> > > > > >>be made available
> > > > > >>during the rewind phase. The easiest way is to
> > > > > >>persist the data. When
> > > > > >>the page rewinds, it grabs the list.
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>On Dec 18, 2004, at 11:15 PM, J wrote:
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>>Hello All,
> > > > > >>>
> > > > > >>>I have a simple list working following the
> > > > > >>>
> > > > > >>>
> > > > > >>tapestry in
> > > > > >>
> > > > > >>
> > > > > >>>action pp120-132. The thing I'm confused
> > > about
> > > > > >>>though, is if I remove the persistent
> > > property
> > > > > of
> > > > > >>>
> > > > > >>>
> > > > > >>the
> > > > > >>
> > > > > >>
> > > > > >>>list then I start getting stale link errors.
> > > > > >>>
> > > > > >>>Q: I'm wondering why the list doesn't work
> > > the
> > > > > >>>
> > > > > >>>
> > > > > >>same as
> > > > > >>
> > > > > >>
> > > > > >>>the more simple fields without the
> > > persistence?
> > > > > >>>
> > > > > >>>For example, the simple text entry fields
> > > keep
> > > > > >>>
> > > > > >>>
> > > > > >>their
> > > > > >>
> > > > > >>
> > > > > >>>state OK when posting back. When I remove
> > > the
> > > > > >>>persistent property of the list the first
> > > post
> > > > > >>>
> > >
> > === message truncated ===
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Take Yahoo! Mail with you! Get it on your mobile phone.
> > http://mobile.yahoo.com/maildemo
> >
> > ---------------------------------------------------------------------
> > 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: Newbie Q: Lists and persistent property
Posted by Bryan Lewis <br...@maine.rr.com>.
Well, I hadn't actually tried the idea, but it ought to work. I've had no
trouble getting to my custom Engine class from my border component, by
calling the enclosing page rather than the RequestCycle like: MyEngine
engine = (MyEngine) getPage().getEngine().
I don't know why cycle.getEngine() isn't working for you. It doesn't seem
right that a simple casting would cause you to get a null return value...
there might be something else wrong.
Anyway, enough hypothesizing. I tried implementing the idea. In my Engine
class I added:
public void discardActivePages(IRequestCycle cycle)
{
Collection pageNames = getActivePageNames();
for (Iterator it = pageNames.iterator(); it.hasNext(); ) {
String pageName = (String) it.next();
try {
log.debug("Discarding page " + pageName);
cycle.discardPage(pageName);
}
catch (Exception ex) {
log.debug("Couldn't discard page " + pageName + ", got
exception: "
+ ex.getClass().getName() + "; " + ex.getMessage());
}
}
}
Notice that I renamed it to "discard" rather than "forget". I tried the
forgetPage() technique first but after some stress-testing I got a
java.util.ConcurrentModificationException, so I switched to
cycle.discardPage() as recommended in the wiki page. My menu component
does:
public void menuItemClicked(IRequestCycle cycle)
{
String nextPageName = getMenuItem().getPage();
log.debug("About to activate " + nextPageName + "page; discarding
old pages first.");
((Engine) getPage().getEngine()).discardActivePages(cycle);
// Get the next page and activate it as usual....
}
This works fine for me so far, but I can think of two disclaimers. I
haven't load-tested it to see whether it's actually improving the
performance. And it aggravates the back-button problem... if one is so
foolish as to allow users to back-button to a previous page and click on a
link. I have a large list page (no form, just a long list of links, maybe a
few hundred) that users must be able to go back to and reclick. It was
working before when the list was persistent. Now that the list has been
discarded I get a StaleLink exception. At least we know that the discarding
is working!
Now, maybe your users are less demanding and a StaleLink is what they
deserve for backing up :-) but I'll have to make this a little less
aggressive. I won't discard the old pages on _every_ menu click but only
when activating one of our two or three large list pages. Our convention
would be, "You can only be working with one large list at a time... as soon
as you go to another one, the old one will be forgotten." I think that'll
satisfy the way our users work, and it'll still clean up our biggest memory
hogs. (I wouldn't be surprised, though, if we judge this to be not worth
the effort. Maybe we should just buy more memory for the server. I'd be
interested to hear if it actually helps your performance.)
----- Original Message -----
From: "J" <ja...@yahoo.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Thursday, December 23, 2004 10:52 AM
Subject: Re: Newbie Q: Lists and persistent property
> Hi Bryan,
>
> I like your idea - tried to give it a try and ran into
> problems. I tried implementing forgetAllActivePages()
> in a subclass of the engine. The problem I have is
> getting a handle to the subclass in the border
> component:
>
> -IEngine engine = cycle.getEngine(); works just fine,
> but this doesn't get to the subclass
> -tried casting a la: BaseEngineSub engine =
> (BaseEngineSub) cycle.getEngine();, but this comes
> back with a null
> -tried implementing the IPage i/f in the component and
> using the getVisit() method like I saw in the vlib,
> but Tapestry returns an error that the Component null
> may not implement the IPage interface
>
> Did you get this to fly? If so, how are you getting a
> handle to the subclassed engine in the border class?
>
> Jason
>
> --- Bryan Lewis <br...@maine.rr.com> wrote:
>
> > Doesn't sound too kludgy to me, given the current
> > state of things. I was
> > thinking about trying this kind of house-cleaning in
> > my border's navigation
> > menu. When users click on a menu link, it would
> > signify they're done with
> > whatever page they were on.
> >
> > Is it really necessary for each page to add itself
> > to a vector in
> > pageBeginRender()? I was hoping to avoid that by
> > providing a method in the
> > engine -- let's call it forgetAllActivePages() --
> > that iterates through the
> > collection of all remembered pages --
> > engine.getActivePageNames() -- and
> > calls forgetPage() on each one. Then it's only
> > necessary that the menu code
> > call engine.forgetAllActivePages(), which is one
> > line of code in one place.
> >
> >
> > ----- Original Message -----
> > From: "J" <ja...@yahoo.com>
> > To: "Tapestry users"
> > <ta...@jakarta.apache.org>
> > Sent: Monday, December 20, 2004 8:30 PM
> > Subject: Re: Newbie Q: Lists and persistent property
> >
> >
> > > Thanks Danny,
> > >
> > > That helped with one part of the problem.
> > >
> > > In case somebody else runs into this, here's what
> > I
> > > did for the other part of the problem: the page
> > with
> > > the persistent data is contained within a border
> > > component that has a menu structure on the left
> > > (modeled after the virtual lib). The user
> > inserted a
> > > few list items, then clicked on a link in the
> > border
> > > that triggered a listener in the border - not in
> > the
> > > contained page with the persistent state - so the
> > > contained page is not forwarding to another page
> > and
> > > can not clean up after itself. Then they clicked
> > back
> > > to the page and the half composed list was still
> > > there.
> > >
> > > ...perhaps this should be cast as a feature? ;-)
> > >
> > > Anyway, the user expected the list to be cleared.
> > So
> > > what I did feels a bit kludgy, but it worked:
> > > -added a Vector called 'pagesToForget' to the
> > visit
> > > object
> > > -In the page with the persistent data, in the
> > > pageBeginRender method I get the visit and add the
> > > page to the Vector with something like
> > >
> > ...getPagesToForget().add(getPage().getPageName());
> > > -In the border, for each listener I grab the visit
> > > object, iterate over the pagesToForget, and
> > discard
> > > any pages that were added
> > >
> > > It feels kludgy because another component (the
> > border)
> > > is cleaning up after the other pages with
> > persistent
> > > state, but it works. If anybody has a better way
> > of
> > > cleaning up pls let me know.
> > >
> > > Jason
> > >
> > > --- Danny Mandel <dm...@tolweb.org> wrote:
> > >
> > > > Hi Jason. Have a look at this wiki page:
> > > >
> > > >
> > >
> >
> http://wiki.apache.org/jakarta-tapestry/ClearingPersistentProperties
> > > >
> > > > Hope that helps,
> > > > Danny
> > > >
> > > > J wrote:
> > > >
> > > > >That makes sense, thank you.
> > > > >
> > > > >On a related note, I'm curious about the best
> > way
> > > > to
> > > > >reset the persistent data in a menu driven app
> > like
> > > > >the virtual lib (I searched the vlib example
> > and
> > > > >couldn't see an answer to this Q).
> > > > >
> > > > >For example, I see how I can reset the data on
> > a
> > > > page
> > > > >submit within the class before moving to
> > another
> > > > page
> > > > >by doing a
> > > > 'setItems(null);cycle.activate(nextPage);'
> > > > >
> > > > >However, what about if the user clicks on a
> > menu
> > > > >within the border component, then clicks back?
> > The
> > > > >simple fields are reset OK, but the persistent
> > data
> > > > is
> > > > >not. The only alternative I see is to detect
> > that
> > > > it
> > > > >is a 'new visit' to the page in the
> > > > pageBeginRender()
> > > > >method somehow and reset the list to null
> > there.
> > > > >
> > > > >Q: is there a better way to reset the
> > persistent
> > > > data?
> > > > >
> > > > >Jason
> > > > >
> > > > >--- Jamie Orchard-Hays <ja...@dang.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > >>The simple fields are being submitted with the
> > > > form,
> > > > >>so there is data
> > > > >>for them available during the rewind. The list
> > > > >>itself is not stored on
> > > > >>or submitted by the web page, so that data
> > needs
> > > > to
> > > > >>be made available
> > > > >>during the rewind phase. The easiest way is to
> > > > >>persist the data. When
> > > > >>the page rewinds, it grabs the list.
> > > > >>
> > > > >>
> > > > >>
> > > > >>On Dec 18, 2004, at 11:15 PM, J wrote:
> > > > >>
> > > > >>
> > > > >>
> > > > >>>Hello All,
> > > > >>>
> > > > >>>I have a simple list working following the
> > > > >>>
> > > > >>>
> > > > >>tapestry in
> > > > >>
> > > > >>
> > > > >>>action pp120-132. The thing I'm confused
> > about
> > > > >>>though, is if I remove the persistent
> > property
> > > > of
> > > > >>>
> > > > >>>
> > > > >>the
> > > > >>
> > > > >>
> > > > >>>list then I start getting stale link errors.
> > > > >>>
> > > > >>>Q: I'm wondering why the list doesn't work
> > the
> > > > >>>
> > > > >>>
> > > > >>same as
> > > > >>
> > > > >>
> > > > >>>the more simple fields without the
> > persistence?
> > > > >>>
> > > > >>>For example, the simple text entry fields
> > keep
> > > > >>>
> > > > >>>
> > > > >>their
> > > > >>
> > > > >>
> > > > >>>state OK when posting back. When I remove
> > the
> > > > >>>persistent property of the list the first
> > post
> > > > >>>
> >
> === message truncated ===
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Take Yahoo! Mail with you! Get it on your mobile phone.
> http://mobile.yahoo.com/maildemo
>
> ---------------------------------------------------------------------
> 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: Newbie Q: Lists and persistent property
Posted by J <ja...@yahoo.com>.
Hi Bryan,
I like your idea - tried to give it a try and ran into
problems. I tried implementing forgetAllActivePages()
in a subclass of the engine. The problem I have is
getting a handle to the subclass in the border
component:
-IEngine engine = cycle.getEngine(); works just fine,
but this doesn't get to the subclass
-tried casting a la: BaseEngineSub engine =
(BaseEngineSub) cycle.getEngine();, but this comes
back with a null
-tried implementing the IPage i/f in the component and
using the getVisit() method like I saw in the vlib,
but Tapestry returns an error that the Component null
may not implement the IPage interface
Did you get this to fly? If so, how are you getting a
handle to the subclassed engine in the border class?
Jason
--- Bryan Lewis <br...@maine.rr.com> wrote:
> Doesn't sound too kludgy to me, given the current
> state of things. I was
> thinking about trying this kind of house-cleaning in
> my border's navigation
> menu. When users click on a menu link, it would
> signify they're done with
> whatever page they were on.
>
> Is it really necessary for each page to add itself
> to a vector in
> pageBeginRender()? I was hoping to avoid that by
> providing a method in the
> engine -- let's call it forgetAllActivePages() --
> that iterates through the
> collection of all remembered pages --
> engine.getActivePageNames() -- and
> calls forgetPage() on each one. Then it's only
> necessary that the menu code
> call engine.forgetAllActivePages(), which is one
> line of code in one place.
>
>
> ----- Original Message -----
> From: "J" <ja...@yahoo.com>
> To: "Tapestry users"
> <ta...@jakarta.apache.org>
> Sent: Monday, December 20, 2004 8:30 PM
> Subject: Re: Newbie Q: Lists and persistent property
>
>
> > Thanks Danny,
> >
> > That helped with one part of the problem.
> >
> > In case somebody else runs into this, here's what
> I
> > did for the other part of the problem: the page
> with
> > the persistent data is contained within a border
> > component that has a menu structure on the left
> > (modeled after the virtual lib). The user
> inserted a
> > few list items, then clicked on a link in the
> border
> > that triggered a listener in the border - not in
> the
> > contained page with the persistent state - so the
> > contained page is not forwarding to another page
> and
> > can not clean up after itself. Then they clicked
> back
> > to the page and the half composed list was still
> > there.
> >
> > ...perhaps this should be cast as a feature? ;-)
> >
> > Anyway, the user expected the list to be cleared.
> So
> > what I did feels a bit kludgy, but it worked:
> > -added a Vector called 'pagesToForget' to the
> visit
> > object
> > -In the page with the persistent data, in the
> > pageBeginRender method I get the visit and add the
> > page to the Vector with something like
> >
> ...getPagesToForget().add(getPage().getPageName());
> > -In the border, for each listener I grab the visit
> > object, iterate over the pagesToForget, and
> discard
> > any pages that were added
> >
> > It feels kludgy because another component (the
> border)
> > is cleaning up after the other pages with
> persistent
> > state, but it works. If anybody has a better way
> of
> > cleaning up pls let me know.
> >
> > Jason
> >
> > --- Danny Mandel <dm...@tolweb.org> wrote:
> >
> > > Hi Jason. Have a look at this wiki page:
> > >
> > >
> >
>
http://wiki.apache.org/jakarta-tapestry/ClearingPersistentProperties
> > >
> > > Hope that helps,
> > > Danny
> > >
> > > J wrote:
> > >
> > > >That makes sense, thank you.
> > > >
> > > >On a related note, I'm curious about the best
> way
> > > to
> > > >reset the persistent data in a menu driven app
> like
> > > >the virtual lib (I searched the vlib example
> and
> > > >couldn't see an answer to this Q).
> > > >
> > > >For example, I see how I can reset the data on
> a
> > > page
> > > >submit within the class before moving to
> another
> > > page
> > > >by doing a
> > > 'setItems(null);cycle.activate(nextPage);'
> > > >
> > > >However, what about if the user clicks on a
> menu
> > > >within the border component, then clicks back?
> The
> > > >simple fields are reset OK, but the persistent
> data
> > > is
> > > >not. The only alternative I see is to detect
> that
> > > it
> > > >is a 'new visit' to the page in the
> > > pageBeginRender()
> > > >method somehow and reset the list to null
> there.
> > > >
> > > >Q: is there a better way to reset the
> persistent
> > > data?
> > > >
> > > >Jason
> > > >
> > > >--- Jamie Orchard-Hays <ja...@dang.com> wrote:
> > > >
> > > >
> > > >
> > > >>The simple fields are being submitted with the
> > > form,
> > > >>so there is data
> > > >>for them available during the rewind. The list
> > > >>itself is not stored on
> > > >>or submitted by the web page, so that data
> needs
> > > to
> > > >>be made available
> > > >>during the rewind phase. The easiest way is to
> > > >>persist the data. When
> > > >>the page rewinds, it grabs the list.
> > > >>
> > > >>
> > > >>
> > > >>On Dec 18, 2004, at 11:15 PM, J wrote:
> > > >>
> > > >>
> > > >>
> > > >>>Hello All,
> > > >>>
> > > >>>I have a simple list working following the
> > > >>>
> > > >>>
> > > >>tapestry in
> > > >>
> > > >>
> > > >>>action pp120-132. The thing I'm confused
> about
> > > >>>though, is if I remove the persistent
> property
> > > of
> > > >>>
> > > >>>
> > > >>the
> > > >>
> > > >>
> > > >>>list then I start getting stale link errors.
> > > >>>
> > > >>>Q: I'm wondering why the list doesn't work
> the
> > > >>>
> > > >>>
> > > >>same as
> > > >>
> > > >>
> > > >>>the more simple fields without the
> persistence?
> > > >>>
> > > >>>For example, the simple text entry fields
> keep
> > > >>>
> > > >>>
> > > >>their
> > > >>
> > > >>
> > > >>>state OK when posting back. When I remove
> the
> > > >>>persistent property of the list the first
> post
> > > >>>
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Newbie Q: Lists and persistent property
Posted by Bryan Lewis <br...@maine.rr.com>.
Doesn't sound too kludgy to me, given the current state of things. I was
thinking about trying this kind of house-cleaning in my border's navigation
menu. When users click on a menu link, it would signify they're done with
whatever page they were on.
Is it really necessary for each page to add itself to a vector in
pageBeginRender()? I was hoping to avoid that by providing a method in the
engine -- let's call it forgetAllActivePages() -- that iterates through the
collection of all remembered pages -- engine.getActivePageNames() -- and
calls forgetPage() on each one. Then it's only necessary that the menu code
call engine.forgetAllActivePages(), which is one line of code in one place.
----- Original Message -----
From: "J" <ja...@yahoo.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Monday, December 20, 2004 8:30 PM
Subject: Re: Newbie Q: Lists and persistent property
> Thanks Danny,
>
> That helped with one part of the problem.
>
> In case somebody else runs into this, here's what I
> did for the other part of the problem: the page with
> the persistent data is contained within a border
> component that has a menu structure on the left
> (modeled after the virtual lib). The user inserted a
> few list items, then clicked on a link in the border
> that triggered a listener in the border - not in the
> contained page with the persistent state - so the
> contained page is not forwarding to another page and
> can not clean up after itself. Then they clicked back
> to the page and the half composed list was still
> there.
>
> ...perhaps this should be cast as a feature? ;-)
>
> Anyway, the user expected the list to be cleared. So
> what I did feels a bit kludgy, but it worked:
> -added a Vector called 'pagesToForget' to the visit
> object
> -In the page with the persistent data, in the
> pageBeginRender method I get the visit and add the
> page to the Vector with something like
> ...getPagesToForget().add(getPage().getPageName());
> -In the border, for each listener I grab the visit
> object, iterate over the pagesToForget, and discard
> any pages that were added
>
> It feels kludgy because another component (the border)
> is cleaning up after the other pages with persistent
> state, but it works. If anybody has a better way of
> cleaning up pls let me know.
>
> Jason
>
> --- Danny Mandel <dm...@tolweb.org> wrote:
>
> > Hi Jason. Have a look at this wiki page:
> >
> >
> http://wiki.apache.org/jakarta-tapestry/ClearingPersistentProperties
> >
> > Hope that helps,
> > Danny
> >
> > J wrote:
> >
> > >That makes sense, thank you.
> > >
> > >On a related note, I'm curious about the best way
> > to
> > >reset the persistent data in a menu driven app like
> > >the virtual lib (I searched the vlib example and
> > >couldn't see an answer to this Q).
> > >
> > >For example, I see how I can reset the data on a
> > page
> > >submit within the class before moving to another
> > page
> > >by doing a
> > 'setItems(null);cycle.activate(nextPage);'
> > >
> > >However, what about if the user clicks on a menu
> > >within the border component, then clicks back? The
> > >simple fields are reset OK, but the persistent data
> > is
> > >not. The only alternative I see is to detect that
> > it
> > >is a 'new visit' to the page in the
> > pageBeginRender()
> > >method somehow and reset the list to null there.
> > >
> > >Q: is there a better way to reset the persistent
> > data?
> > >
> > >Jason
> > >
> > >--- Jamie Orchard-Hays <ja...@dang.com> wrote:
> > >
> > >
> > >
> > >>The simple fields are being submitted with the
> > form,
> > >>so there is data
> > >>for them available during the rewind. The list
> > >>itself is not stored on
> > >>or submitted by the web page, so that data needs
> > to
> > >>be made available
> > >>during the rewind phase. The easiest way is to
> > >>persist the data. When
> > >>the page rewinds, it grabs the list.
> > >>
> > >>
> > >>
> > >>On Dec 18, 2004, at 11:15 PM, J wrote:
> > >>
> > >>
> > >>
> > >>>Hello All,
> > >>>
> > >>>I have a simple list working following the
> > >>>
> > >>>
> > >>tapestry in
> > >>
> > >>
> > >>>action pp120-132. The thing I'm confused about
> > >>>though, is if I remove the persistent property
> > of
> > >>>
> > >>>
> > >>the
> > >>
> > >>
> > >>>list then I start getting stale link errors.
> > >>>
> > >>>Q: I'm wondering why the list doesn't work the
> > >>>
> > >>>
> > >>same as
> > >>
> > >>
> > >>>the more simple fields without the persistence?
> > >>>
> > >>>For example, the simple text entry fields keep
> > >>>
> > >>>
> > >>their
> > >>
> > >>
> > >>>state OK when posting back. When I remove the
> > >>>persistent property of the list the first post
> > >>>
> > >>>
> > >>back
> > >>
> > >>
> > >>>works and adds an item, but all subsequent post
> > >>>
> > >>>
> > >>backs
> > >>
> > >>
> > >>>result in the stale link error.
> > >>>
> > >>>Jason
> > >>>
> >
> >>>__________________________________________________
> > >>>Do You Yahoo!?
> > >>>Tired of spam? Yahoo! Mail has the best spam
> > >>>
> > >>>
> > >>protection around
> > >>
> > >>
> > >>>http://mail.yahoo.com
> > >>>
> > >>>
> > >>>
> > >>>
> >
> >---------------------------------------------------------------------
> > >
> > >
> > >>>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
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > >__________________________________
> > >Do you Yahoo!?
> > >All your favorites on one personal page - Try My
> > Yahoo!
> > >http://my.yahoo.com
> > >
> >
> >---------------------------------------------------------------------
> > >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
> >
> >
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Helps protect you from nasty viruses.
> http://promotions.yahoo.com/new_mail
>
> ---------------------------------------------------------------------
> 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: Newbie Q: Lists and persistent property
Posted by J <ja...@yahoo.com>.
Thanks Danny,
That helped with one part of the problem.
In case somebody else runs into this, here's what I
did for the other part of the problem: the page with
the persistent data is contained within a border
component that has a menu structure on the left
(modeled after the virtual lib). The user inserted a
few list items, then clicked on a link in the border
that triggered a listener in the border - not in the
contained page with the persistent state - so the
contained page is not forwarding to another page and
can not clean up after itself. Then they clicked back
to the page and the half composed list was still
there.
...perhaps this should be cast as a feature? ;-)
Anyway, the user expected the list to be cleared. So
what I did feels a bit kludgy, but it worked:
-added a Vector called 'pagesToForget' to the visit
object
-In the page with the persistent data, in the
pageBeginRender method I get the visit and add the
page to the Vector with something like
...getPagesToForget().add(getPage().getPageName());
-In the border, for each listener I grab the visit
object, iterate over the pagesToForget, and discard
any pages that were added
It feels kludgy because another component (the border)
is cleaning up after the other pages with persistent
state, but it works. If anybody has a better way of
cleaning up pls let me know.
Jason
--- Danny Mandel <dm...@tolweb.org> wrote:
> Hi Jason. Have a look at this wiki page:
>
>
http://wiki.apache.org/jakarta-tapestry/ClearingPersistentProperties
>
> Hope that helps,
> Danny
>
> J wrote:
>
> >That makes sense, thank you.
> >
> >On a related note, I'm curious about the best way
> to
> >reset the persistent data in a menu driven app like
> >the virtual lib (I searched the vlib example and
> >couldn't see an answer to this Q).
> >
> >For example, I see how I can reset the data on a
> page
> >submit within the class before moving to another
> page
> >by doing a
> 'setItems(null);cycle.activate(nextPage);'
> >
> >However, what about if the user clicks on a menu
> >within the border component, then clicks back? The
> >simple fields are reset OK, but the persistent data
> is
> >not. The only alternative I see is to detect that
> it
> >is a 'new visit' to the page in the
> pageBeginRender()
> >method somehow and reset the list to null there.
> >
> >Q: is there a better way to reset the persistent
> data?
> >
> >Jason
> >
> >--- Jamie Orchard-Hays <ja...@dang.com> wrote:
> >
> >
> >
> >>The simple fields are being submitted with the
> form,
> >>so there is data
> >>for them available during the rewind. The list
> >>itself is not stored on
> >>or submitted by the web page, so that data needs
> to
> >>be made available
> >>during the rewind phase. The easiest way is to
> >>persist the data. When
> >>the page rewinds, it grabs the list.
> >>
> >>
> >>
> >>On Dec 18, 2004, at 11:15 PM, J wrote:
> >>
> >>
> >>
> >>>Hello All,
> >>>
> >>>I have a simple list working following the
> >>>
> >>>
> >>tapestry in
> >>
> >>
> >>>action pp120-132. The thing I'm confused about
> >>>though, is if I remove the persistent property
> of
> >>>
> >>>
> >>the
> >>
> >>
> >>>list then I start getting stale link errors.
> >>>
> >>>Q: I'm wondering why the list doesn't work the
> >>>
> >>>
> >>same as
> >>
> >>
> >>>the more simple fields without the persistence?
> >>>
> >>>For example, the simple text entry fields keep
> >>>
> >>>
> >>their
> >>
> >>
> >>>state OK when posting back. When I remove the
> >>>persistent property of the list the first post
> >>>
> >>>
> >>back
> >>
> >>
> >>>works and adds an item, but all subsequent post
> >>>
> >>>
> >>backs
> >>
> >>
> >>>result in the stale link error.
> >>>
> >>>Jason
> >>>
>
>>>__________________________________________________
> >>>Do You Yahoo!?
> >>>Tired of spam? Yahoo! Mail has the best spam
> >>>
> >>>
> >>protection around
> >>
> >>
> >>>http://mail.yahoo.com
> >>>
> >>>
> >>>
> >>>
>
>---------------------------------------------------------------------
> >
> >
> >>>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
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >__________________________________
> >Do you Yahoo!?
> >All your favorites on one personal page � Try My
> Yahoo!
> >http://my.yahoo.com
> >
>
>---------------------------------------------------------------------
> >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
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Newbie Q: Lists and persistent property
Posted by Danny Mandel <dm...@tolweb.org>.
Hi Jason. Have a look at this wiki page:
http://wiki.apache.org/jakarta-tapestry/ClearingPersistentProperties
Hope that helps,
Danny
J wrote:
>That makes sense, thank you.
>
>On a related note, I'm curious about the best way to
>reset the persistent data in a menu driven app like
>the virtual lib (I searched the vlib example and
>couldn't see an answer to this Q).
>
>For example, I see how I can reset the data on a page
>submit within the class before moving to another page
>by doing a 'setItems(null);cycle.activate(nextPage);'
>
>However, what about if the user clicks on a menu
>within the border component, then clicks back? The
>simple fields are reset OK, but the persistent data is
>not. The only alternative I see is to detect that it
>is a 'new visit' to the page in the pageBeginRender()
>method somehow and reset the list to null there.
>
>Q: is there a better way to reset the persistent data?
>
>Jason
>
>--- Jamie Orchard-Hays <ja...@dang.com> wrote:
>
>
>
>>The simple fields are being submitted with the form,
>>so there is data
>>for them available during the rewind. The list
>>itself is not stored on
>>or submitted by the web page, so that data needs to
>>be made available
>>during the rewind phase. The easiest way is to
>>persist the data. When
>>the page rewinds, it grabs the list.
>>
>>
>>
>>On Dec 18, 2004, at 11:15 PM, J wrote:
>>
>>
>>
>>>Hello All,
>>>
>>>I have a simple list working following the
>>>
>>>
>>tapestry in
>>
>>
>>>action pp120-132. The thing I'm confused about
>>>though, is if I remove the persistent property of
>>>
>>>
>>the
>>
>>
>>>list then I start getting stale link errors.
>>>
>>>Q: I'm wondering why the list doesn't work the
>>>
>>>
>>same as
>>
>>
>>>the more simple fields without the persistence?
>>>
>>>For example, the simple text entry fields keep
>>>
>>>
>>their
>>
>>
>>>state OK when posting back. When I remove the
>>>persistent property of the list the first post
>>>
>>>
>>back
>>
>>
>>>works and adds an item, but all subsequent post
>>>
>>>
>>backs
>>
>>
>>>result in the stale link error.
>>>
>>>Jason
>>>
>>>__________________________________________________
>>>Do You Yahoo!?
>>>Tired of spam? Yahoo! Mail has the best spam
>>>
>>>
>>protection around
>>
>>
>>>http://mail.yahoo.com
>>>
>>>
>>>
>>>
>---------------------------------------------------------------------
>
>
>>>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
>>
>>
>>
>>
>
>
>
>
>__________________________________
>Do you Yahoo!?
>All your favorites on one personal page – Try My Yahoo!
>http://my.yahoo.com
>
>---------------------------------------------------------------------
>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: Newbie Q: Lists and persistent property
Posted by J <ja...@yahoo.com>.
That makes sense, thank you.
On a related note, I'm curious about the best way to
reset the persistent data in a menu driven app like
the virtual lib (I searched the vlib example and
couldn't see an answer to this Q).
For example, I see how I can reset the data on a page
submit within the class before moving to another page
by doing a 'setItems(null);cycle.activate(nextPage);'
However, what about if the user clicks on a menu
within the border component, then clicks back? The
simple fields are reset OK, but the persistent data is
not. The only alternative I see is to detect that it
is a 'new visit' to the page in the pageBeginRender()
method somehow and reset the list to null there.
Q: is there a better way to reset the persistent data?
Jason
--- Jamie Orchard-Hays <ja...@dang.com> wrote:
> The simple fields are being submitted with the form,
> so there is data
> for them available during the rewind. The list
> itself is not stored on
> or submitted by the web page, so that data needs to
> be made available
> during the rewind phase. The easiest way is to
> persist the data. When
> the page rewinds, it grabs the list.
>
>
>
> On Dec 18, 2004, at 11:15 PM, J wrote:
>
> > Hello All,
> >
> > I have a simple list working following the
> tapestry in
> > action pp120-132. The thing I'm confused about
> > though, is if I remove the persistent property of
> the
> > list then I start getting stale link errors.
> >
> > Q: I'm wondering why the list doesn't work the
> same as
> > the more simple fields without the persistence?
> >
> > For example, the simple text entry fields keep
> their
> > state OK when posting back. When I remove the
> > persistent property of the list the first post
> back
> > works and adds an item, but all subsequent post
> backs
> > result in the stale link error.
> >
> > Jason
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> >
> >
>
---------------------------------------------------------------------
> > 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
>
>
__________________________________
Do you Yahoo!?
All your favorites on one personal page � Try My Yahoo!
http://my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Newbie Q: Lists and persistent property
Posted by Jamie Orchard-Hays <ja...@dang.com>.
The simple fields are being submitted with the form, so there is data
for them available during the rewind. The list itself is not stored on
or submitted by the web page, so that data needs to be made available
during the rewind phase. The easiest way is to persist the data. When
the page rewinds, it grabs the list.
On Dec 18, 2004, at 11:15 PM, J wrote:
> Hello All,
>
> I have a simple list working following the tapestry in
> action pp120-132. The thing I'm confused about
> though, is if I remove the persistent property of the
> list then I start getting stale link errors.
>
> Q: I'm wondering why the list doesn't work the same as
> the more simple fields without the persistence?
>
> For example, the simple text entry fields keep their
> state OK when posting back. When I remove the
> persistent property of the list the first post back
> works and adds an item, but all subsequent post backs
> result in the stale link error.
>
> Jason
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> 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