Hi Alex
Consider this not as an answer but as a comment :)
I think the more I understand tapestry the less I used @Persist. I take it as a
challenge to minimize the use of @Persist and even have a count of number of
@Persist's I am using in a given application. I use context and have been able
to avoid @Persist to such a level that I have applications which use no
@Persist at all.
So for me @Persist is more of a work around to keep things in a page that you
can't(lack of context in 3rd party components) or won't(secure data) send to
the client and which has no relevance outside the page.
As for @SessionState, again I avoid it but if I have to use it I prefer to have
a service using ApplicationState underneath.
@Persist("session") serializes the value into the session where as
@Persist("entity") only serializes a key(entity_id, entity_type) and retrieves
it for each request from the database.
Hope it helps.
regards
Taha
On Jan 3, 2013, at 9:42 PM, Alex Kotchnev wrote:
> In the last few weeks I ran into a few instances of what I thought was
> inappropriate usage of @Persist("session") on fields in pages and
> components in our codebase; however, after thinking about it some more I
> realized that I don't quite have a crisp definition of what an appropriate
> usage is. It seems that @Persist in pages/components is somewhat of a
> middle ground between activation parameters (and generally, request
> parameters) and the "traditional" usage of a Session in servlet
> applications, and there probably are good patterns/examples of appropriate
> and inappropriate usage.
>
> In general the more traditional "session" storage from straight-up
> Serlvet/JSP world is represented using @SessionState - that is, state that
> is stored in the session and can be used across different pages and events
> (e.g. user specific values that are handy to have between requests in
> different locations in the application such as the user's ID, maybe
> permissions and roles,etc).
>
> Now, as far as I understand, @Persist("session") stores the value in the
> session, keyed on the component class (e.g. thus in component A, a field
> "@Persist private String fooMessage" would/could store a different value
> than "@Persist private String fooMessage" in component B). However, I'm
> not 100% clear is whether if I have "@Persist private String fooMessage" in
> two different instances of the component - would they have the same value
> ?
>
> The second example is with marking JPA entities with @Persist. My initial
> reaction was that of horror, thinking that it would result in too much
> state stored in the session. But then I wondered, maybe Tapestry uses the
> same approach used w/ activation parameters and could just store the key to
> the entity.
>
> All in all, I would appreciate some examples of appropriate and
> inappropriate usage of @Persist in pages and components from your
> experiences.
>
> Cheers - Alex Kochnev
