You got me; my eyes are blurry from too much laptop time.
Pages and components are supposed to automatically implement
PageDetachListener and provide an implementation that clears out
instance variables. I'll have to run some experiments.
On 8/8/05, Paul Cantrell <[EMAIL PROTECTED]> wrote:
> Well, yes, that's how it's supposed to work, of course, but it's
> *clearly* not the behavior I'm getting!
>
> Check the original message a bit more carefully -- I *don't want* my
> properties persisted, but that's what's happening to them.
>
> Cheers,
>
> Paul
>
> On Aug 8, 2005, at 6:28 PM, Howard Lewis Ship wrote:
>
> > Only properties marked persistent are persisted between requests.
> > Other properties are transients.
> >
> > @Persist
> > public abstract String getArticleTitle();
> > public abstract void setArticleTitle(String title);
> >
> > @Persist
> > public abstract String getArticleBody();
> > public abstract void setArticleBody(String bodyText);
> >
> >
> > Alternately, your .page file can say:
> >
> > <property name="articleTitle" persist="session"/>
> > <property name="articleBody" persist="session"/>
> >
> >
> >
> > On 8/8/05, Paul `Order in Chaos` Cantrell <[EMAIL PROTECTED]> wrote:
> >
> >> An addendum to my earlier note, to file under "curiouser and
> >> curiouser":
> >>
> >> If I implement PageDetachListener, everything works as expected --
> >> even if my pageDetached() does nothing!
> >>
> >> public abstract class MyPage
> >> extends BasePage
> >> implements PageDetachListener
> >> {
> >> // empty method is fix for bug in Tapestry 4.0b3
> >> public void pageDetached(PageEvent event) { }
> >> ...
> >> }
> >>
> >> Wacky.
> >>
> >>
> >> On Aug 8, 2005, at 12:17 PM, Paul Cantrell wrote:
> >>
> >>
> >>> I thought, what with the nifty annotations, that it should be
> >>> possible to eliminate .page files entirely in most if not all
> >>> cases, thus eliminating a major source of file clutter. Yay!
> >>>
> >>> So I tried it, and found that my page properties were suddenly not
> >>> getting restored to their pristine state. Boo! For example, I have
> >>> this page with two transient properties...
> >>>
> >>> public abstract class ArticleView
> >>> extends BasePage
> >>> implements PageAttachListener
> >>> {
> >>> public void pageAttached(PageEvent event)
> >>> {
> >>> System.out.println("--------------------> title = " +
> >>> getArticleTitle());
> >>> System.out.println("--------------------> body = " +
> >>> getArticleBody());
> >>> }
> >>>
> >>> public void init(Article article)
> >>> {
> >>> setArticleTitle(article.getCurrentVersion().getTitle());
> >>> setArticleBody(article.getCurrentVersion().getBody());
> >>> }
> >>>
> >>> public abstract String getArticleTitle();
> >>> protected abstract void setArticleTitle(String title);
> >>>
> >>> public abstract String getArticleBody();
> >>> protected abstract void setArticleBody(String bodyText);
> >>> }
> >>>
> >>> If I follow a @PageLink to ArticleView, I see title=null, body=null
> >>> -- the correct pristine state. I then populate the page in a
> >>> listener on another page that calls init(), and see the article
> >>> displayed correctly.
> >>>
> >>> But if I then go back to the original @PageLink, the previously
> >>> displayed values, which should have been cleared to null, are still
> >>> there hanging around -- even in pageAttached()! The page object is
> >>> never returned to its pristine state.
> >>>
> >>> If I create a .page file, then everything starts working as
> >>> expected -- my transient properties are correctly cleared for each
> >>> request:
> >>>
> >>> <page-specification class="net.innig.imre.web.ArticleView">
> >>> <property name="articleTitle" />
> >>> <property name="articleBody" />
> >>> </page-specification>
> >>>
> >>> But here's were it gets really weird. If I only specify *one* of
> >>> the two properties, like this:
> >>>
> >>> <page-specification class="net.innig.imre.web.ArticleView">
> >>> <property name="articleTitle" />
> >>> </page-specification>
> >>>
> >>> ...then *both* properties get cleared. It looks like there's some
> >>> "reset page" hook that doesn't get called unless there is a .page
> >>> spec with at least one property in it.
> >>>
> >>> This smells like a bug to me. Am I missing something here (see
> >>> sig)? I really shouldn't need any .page at all, and the app should
> >>> still behave correctly. At the very least, the presence of a spec
> >>> for one property shouldn't change the behavior of all the others.
> >>>
> >>> I am using 4.0 beta 3.
> >>>
> >>> Cheers,
> >>>
> >>> Paul
> >>>
> >>> _________________________________________________________________
> >>>
> >>> "After hearing ten thousand explanations, a fool is no wiser.
> >>> But an intelligent person needs only two thousand five hundred."
> >>> -- Mahabharata
> _________________________________________________________________
>
> "Prediction is hard, especially of the future." -- Niels Bohr
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
