Hi Kristian, >From your post I inferred that you have integrated Spring Web Flow and Tapestry 5 in some way. I was just about to start this. Are you using tapestry 5 pages as the views but still using Spring WebFlow FormActions for the actions? Did you have to write a custom View Resolver? Did you have to write some code (like the FlowAction in Spring WebFlow) to integrate launching and ending a flow from a Tapestry request?
I'd be very interesting in seeing any code that you might be willing to share. Many thanks in advance Russell -----Original Message----- From: Kristian Marinkovic [mailto:[EMAIL PROTECTED] Sent: 16 September 2008 14:19 To: Tapestry users Subject: Re: T5: ApplicationStateObject is misleading hi lubor, IMHO, there is a much simpler and more elegant solution: in order to save my data in a conversation state object i wrote a decorator for the PersistentFieldManager intercepting every @Persist annotation if a conversaion is active. And you can define an own persistence strategy.... @Persist("conversation") as well :) I'm no native speaker but ApplicationStateObject is quite fine for me... it means to me, that there is one object somewhere (instance) that is the same in the whole application. g, kris "Lubor Gajda" <[EMAIL PROTECTED]> 16.09.2008 14:40 Bitte antworten an "Tapestry users" <users@tapestry.apache.org> An "Tapestry users" <users@tapestry.apache.org> Kopie Thema Re: T5: ApplicationStateObject is misleading Hi Geoff, I absolutely agree with you that concept of ASO objects and persistent properties is one of few downsides of current Tapestry implementation. I came across this type of problems recently when I was experimenting with Tapestry & Spring Web Flow integration. One of the issues that I had to solve was to find simple solution how from tapestry pages access objects stored in different webflow scopes. To achieve this goal I couldn't use neither persistent properties nor ASO. Persisted properties can't be shared between different pages in the same flow and ASO objects require additional configuration if you want to use non default persistence strategy (to complicated solution). Therefore I was forced to develop my own solution which is based on my custom ScopeWorker that allows page properties to be annotated by my custom @Scope annotation: public class MyPage { @Scope(SESSION) private User user; @Scope(FLOW) private Facility facility; ... } @Scope annotation can be used with different scope types (APPLICATION, SESSION, CONVERSATION, FLOW, FLASH, PAGE, REQUEST, etc.) to access objects stored in these scopes (when object is not found in the scope it's automatically created). I think that it would be good idea to find (in some future Tapestry release) simple generic solution for scoping page properties that would replace currently used ASO and Persist strategies (these could be marked as obsolete and kept for backward compatibility reasons). Regards Lubor On Tue, Sep 16, 2008 at 12:49 PM, Inge Solvoll <[EMAIL PROTECTED]>wrote: > I agree, I've always found the term "ApplicationState" to be a bit > confusing. > > Some more ideas: > > @UserState > @SessionState > @SessionPersist > @SaveItForLater (kidding) > > On Tue, Sep 16, 2008 at 1:06 PM, Geoff Callender < > [EMAIL PROTECTED]> wrote: > > > We want Tapestry to be as natural as possible for newcomers, so it's > > important to have terminology that is not misleading. Right now might be > the > > last chance to tidy some of these up before T5.0 goes final. > > > > One term that I believe many people find misleading is ApplicationState. > > The problem is that it implies it will make an object available across > the > > whole application, ie. application-scoped; which is not its purpose. > > > > The doco says that ASOs "are unique to an individual user, not shared > > between users", which is not quite right, either. > > > > The standard usage is to tie an object's scope to that of a web session, > so > > maybe we should put "session" in the name? Eg. > > > > @SessionScoped > > @SessionShared > > @ShareAcrossSession > > > > It is important to understand that the term "session" here is NOT a > > reference to the persistence mechanism, but a reference to the scope. > > > > Alternatively, let's keep it really obvious with this: > > > > @StateObject > > > > with the understanding that the default persistence strategy is > "session". > > > > What do others think? Are you happy with ApplicationState? > > > > Geoff > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]