You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Geoff Callender <ge...@gmail.com> on 2008/09/16 13:06:12 UTC
T5: ApplicationStateObject is misleading
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
Re: RE: T5: ApplicationStateObject is misleading NOW T5: Tapestry 5 and
Spring WebFlow
Posted by Kristian Marinkovic <kr...@porsche.co.at>.
hi Russel,
we didn't use Spring WebFlow. We did everything using
Tapestry IOC. Flow starts and ends are marked using own
annotations added to actionMethods.
g,
kris
"Russell Brown" <Ru...@ioko.com>
16.09.2008 17:24
Bitte antworten an
"Tapestry users" <us...@tapestry.apache.org>
An
"Tapestry users" <us...@tapestry.apache.org>
Kopie
Thema
WAS RE: T5: ApplicationStateObject is misleading NOW T5: Tapestry 5 and
Spring WebFlow
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:kristian.marinkovic@porsche.co.at]
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" <lu...@gmail.com>
16.09.2008 14:40
Bitte antworten an
"Tapestry users" <us...@tapestry.apache.org>
An
"Tapestry users" <us...@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
<in...@gmail.com>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 <
> geoff.callender.jumpstart@gmail.com> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
WAS RE: T5: ApplicationStateObject is misleading NOW T5: Tapestry 5 and Spring WebFlow
Posted by Russell Brown <Ru...@ioko.com>.
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:kristian.marinkovic@porsche.co.at]
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" <lu...@gmail.com>
16.09.2008 14:40
Bitte antworten an
"Tapestry users" <us...@tapestry.apache.org>
An
"Tapestry users" <us...@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
<in...@gmail.com>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 <
> geoff.callender.jumpstart@gmail.com> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: ApplicationStateObject is misleading
Posted by Kristian Marinkovic <kr...@porsche.co.at>.
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" <lu...@gmail.com>
16.09.2008 14:40
Bitte antworten an
"Tapestry users" <us...@tapestry.apache.org>
An
"Tapestry users" <us...@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
<in...@gmail.com>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 <
> geoff.callender.jumpstart@gmail.com> 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
>
Re: T5: ApplicationStateObject is misleading
Posted by Lubor Gajda <lu...@gmail.com>.
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 <in...@gmail.com>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 <
> geoff.callender.jumpstart@gmail.com> 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
>
Re: T5: ApplicationStateObject is misleading
Posted by Inge Solvoll <in...@gmail.com>.
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 <
geoff.callender.jumpstart@gmail.com> 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
RE: T5: ApplicationStateObject is misleading
Posted by Jonathan Barker <jo...@gmail.com>.
I think that it's fine. It's not misleading, and it's reasonable to have
framework specific naming.
I also find that it subtly encourages you to collect your state into one or
a small number of state objects.
What I do find lacking is a "discussion" of what should be put into ASO's
versus what should be Persisted, or how something should be persisted. For
many topics, once I move from "great, I got something to work" to "what is
the best way to do this" I find that I spend a lot of time re-inventing best
practices.
Jonathan
> -----Original Message-----
> From: Geoff Callender [mailto:geoff.callender.jumpstart@gmail.com]
> Sent: Tuesday, September 16, 2008 07:06
> To: Tapestry users
> Subject: T5: ApplicationStateObject is misleading
>
> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org