> -----Ursprüngliche Nachricht-----
> Von: Kristian Marinkovic [mailto:[EMAIL PROTECTED]
> Gesendet: Dienstag, 16. September 2008 15:19
> An: Tapestry users
> Betreff: Re: T5: ApplicationStateObject is misleading
> ....
>
> 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
>
Now I'm really confused - and that is the problem Geoff is talking
about ;-)
Is an ApplicationStateObject an Object that is global for the whole
Application and thus the same for every user/Session? Thats what I
would expect from the name.
Or is it globaly accessibl in the application, but different for each
Session - than I would expec an Name like SessionStateObject.
So what is it really?
Thanks, Max
>
>
> 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]
