[ 
https://issues.apache.org/jira/browse/TAPESTRY-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636661#action_12636661
 ] 

Lubor Gajda commented on TAPESTRY-2703:
---------------------------------------

1. I would suggest using enumeration or constants for definition of scope types 
instead of plain strings (to avoid misspelling issues and to support IDE 
auto-completion). For instance:

@Scope(ScopeType.FLOW)
@Scope(ScopeType.CONVERSATION)
@Scope(ScopeType.SESSION)
@Scope(ScopeType.APPLICATION)

With static import this could be simplified to this form:

@Scope(FLOW)
@Scope(CONVERSATION)
@Scope(SESSION)
@Scope(APPLICATION)

2. @Scope(PAGE) as replacement for current @Persist strategy mentioned in 
previous Martin's comment is a bit misleading:

@Persist strategy uses by default HTTP session as storage implementation and 
users should be explicitly aware of that fact (life-cycle of persisted page 
properties is tied to life-cycle of HTTP session and to reset them they have to 
be manually cleaned or the session has to be destroyed). It also conflicts 
naming strategy of JSP API what could be confusing for new Tapestry users not 
100% familiar with its internal terminology.

To avoid this confusion I would use simple:

@Scope(SESSION)
@Scope(FLASH)
@Scope(CLIENT)

However, this would mean that page properties annotated with @Scope(SESSION) 
would be visible from all application pages (so I'm not very sure about this 
one). But I think that @Scope(PAGE) should be reserved for scope type with 
life-cycle identical to page scope used in JSP API.


> ApplicationStateObject is a misleading term
> -------------------------------------------
>
>                 Key: TAPESTRY-2703
>                 URL: https://issues.apache.org/jira/browse/TAPESTRY-2703
>             Project: Tapestry
>          Issue Type: Improvement
>          Components: tapestry-core
>    Affects Versions: 5.0.15
>            Reporter: Geoff Callender
>
> This is a record of a discussion that went on in the mailing list on 16-18 
> Sep 2008.  I proposed that the term ApplicationStateObject caused confusion.  
> Some agreed but not all.  Regardless, the discussion threw up some 
> interesting food for thought, so I've captured it here for further 
> consideration.
> Here's the e-mail that kicked it off.
>       From:   [EMAIL PROTECTED]
>       Subject:        T5: ApplicationStateObject is misleading
>       Date:   16 September 2008 9:06:12 PM
>       To:     [EMAIL PROTECTED]
> 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
> The discussion continued on these 2 threads:
> * http://thread.gmane.org/gmane.comp.java.tapestry.user/65601/focus=65601
> * http://thread.gmane.org/gmane.comp.java.tapestry.user/65638/focus=65638

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to