Re: AW: T5: ApplicationStateObject is misleading
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] > >
RE: AW: T5: ApplicationStateObject is misleading
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]
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]
Re: AW: T5: ApplicationStateObject is misleading
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]
Re: AW: T5: ApplicationStateObject is misleading
@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? -Filip On 2008-09-17 17:36, Geoff Callender wrote: Exactly. To everyone who thinks @ApplicationState is not a misleading term, I would ask you to think back to when you started with T5. Are you sure you didn't think @ApplicationState meant application-wide scope? When I see @ApplicationState today I still do a momentary double-take before I remind myself that only services have application-wide scope. Of course, it would be possible to persist an ASO in a way that achieves application-wide scope, but who has ever done it and why would you? Lubor's suggestion in an earlier thread is compelling - remove all confusion by replacing @Persist and @ApplicationState with @Scope: @Scope(FLASH) @Scope(PAGE) @Scope(CONVERSATION) @Scope(SESSION) @Scope(APPLICATION) I think it deserves serious consideration, don't you? Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: T5: ApplicationStateObject is misleading
Exactly. To everyone who thinks @ApplicationState is not a misleading
term, I would ask you to think back to when you started with T5. Are
you sure you didn't think @ApplicationState meant application-wide
scope? When I see @ApplicationState today I still do a momentary
double-take before I remind myself that only services have application-
wide scope.
Of course, it would be possible to persist an ASO in a way that
achieves application-wide scope, but who has ever done it and why
would you?
Lubor's suggestion in an earlier thread is compelling - remove all
confusion by replacing @Persist and @ApplicationState with @Scope:
@Scope(FLASH)
@Scope(PAGE)
@Scope(CONVERSATION)
@Scope(SESSION)
@Scope(APPLICATION)
I think it deserves serious consideration, don't you?
Geoff
On 18/09/2008, at 1:08 AM, Peter Stavrinides wrote:
ApplicationStateObject is a misnomer, it also got me when I started
T5, what it really is, is a session scoped object (1 per user, per
session), by default Tapestry services that use the @Inject
annotation are singletons (1 per application) as apposed to the
@ApplicationState annotation
- Original Message -
From: "Maximilian Weißböck" <[EMAIL PROTECTED]>
To: "Tapestry users"
Sent: Wednesday, 17 September, 2008 5:52:26 PM GMT +02:00 Athens,
Beirut, Bucharest, Istanbul
Subject: AW: T5: ApplicationStateObject is misleading
-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 i
Re: AW: T5: ApplicationStateObject is misleading
ApplicationStateObject is a misnomer, it also got me when I started T5, what it
really is, is a session scoped object (1 per user, per session), by default
Tapestry services that use the @Inject annotation are singletons (1 per
application) as apposed to the @ApplicationState annotation
- Original Message -
From: "Maximilian Weißböck" <[EMAIL PROTECTED]>
To: "Tapestry users"
Sent: Wednesday, 17 September, 2008 5:52:26 PM GMT +02:00 Athens, Beirut,
Bucharest, Istanbul
Subject: AW: T5: ApplicationStateObject is misleading
> -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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
