By my original post I didn't want to say that current implementation of ASO objects and persistent page properties is illogical or utterly wrong. I understand that it has its internal logic and historical genesis. I just wanted to point out few issues I came across when I was implementing Tapestry & Spring Web Flow integration.
It's probably not a big deal in default Tapestry implementation where we have only two scopes, session (ASO) and page/flash (Persist). However, when you try to integrate Tapestry with something like SWF, which introduces plethora of additional scopes, you will very soon find this mechanism too inflexible and confusing. >From users perspective it should be absolutely transparent what scope is used to determine life-cycle of scoped object and users shouldn't waste development time to meditate on what annotation should be used for a page property (ApplicationState, Persist or something else?). They should automatically choose simple generic strategy and framework should take care of the rest. I think that main historical reason, why we have this framework specific terminology, is that in previous versions of Tapestry there was some intention to absolutely shield users from underlying servlet API and related terminology was replaced by Tapestry specific (session objects were replaced by Visit objects, page scoped objects by persisted objects, etc.). There is nothing wrong with this approach but we have to face the fact that majority of Java developers is more familiar with terms such as session, conversation, flash scope than with ApplicationState and Persist. Try for instance to show following two code snippets to non-tapestry java developers: @ApplicationState private User user; @Scope(SESSION) private User user; Which one do you think will be more confusing for them? Regards Lubor On Wed, Sep 17, 2008 at 6:30 PM, Jonathan Barker < [EMAIL PROTECTED]> wrote: > > There is some logic to what is proposed by Geoff, so it at least merits > consideration and exploration. > > I could see problems arising in the area of uniqueness. We know there's > only > one ASO of a specific class in a T5 app. That's a nice simplification. It > gets fuzzy moving to conversations, and blurry moving to pages. I > routinely > persist more than one of a given class of object on a page, and definitely > don't want to be restricted across pages. > > Are we creating a new set of headaches for the sake of naming consistency? > > Geoff: Perhaps I don't find ASO misleading because I started with T3, so > it's just the evolution of the Visit object. > > Jonathan > > > > -----Original Message----- > > From: Filip S. Adamsen [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, September 17, 2008 12:20 > > To: Tapestry users > > Subject: Re: AW: T5: ApplicationStateObject is misleading > > > > There are still dozens of Tapestry services that will need to be > > changed/rewritten, though. I'm not against this, just saying it's a huge > > change at this point - the way I see it, anyway. > > > > -Filip > > > > On 2008-09-17 18:12, Hilco Wijbenga wrote: > > > On Wed, Sep 17, 2008 at 09:03, Filip S. Adamsen <[EMAIL PROTECTED]> > wrote: > > >> @Scope does, indeed, make more sense than @Persist and > > >> @ApplicationStateObject. I wouldn't mind that change, but is it > > feasible at > > >> this point in Tapestry 5's development cycle? > > > > > > Sure, just deprecate @Persist and @ApplicationStateObject and > > > introduce @Scope as their replacement. All old code will still work > > > and new code can use @Scope. (It's even relatively easy to automate > > > [i.e. script] the move from the old code to the new.) > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
