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]
