Taha - thanks for your comments.
I was also building the application w/ almost no usage of @Persist in my
code. Then, when I started collaborating w/ another developer, he
introduced it in a couple of places. My initial reaction was to remove
them, but that's the time I realized that I didn't have a clear concept of
when it was appropriate to use them. I do get the argument that just for
pure web app scalability reasons, I don't want to store unnecessary data in
the session. Yet, it seems that there would be appropriate usage for it -
otherwise, it wouldn't exist. The one example I've seen in the T5 demo app
where there is a page with a counter that keeps track how many times a user
has clicked a link and the counter could be reset .Then, I wonder, how
often does one need a per-user/per component data that would be just cached
for the duration of a session - e.g. a shopping cart example could use a
@Persist for the items in the shopping cart, but if you needed to display
the shopping cart items elsewhere (e.g. order confirmation page), then
you'd need @SessionState.
Also, thanks for the clarification on the difference between @Persist vs
@Persist("entity"). So, my initial reaction of horror seeing an @Persist on
a pretty heavyweight domain object is well justified - the whole tree of
objects would be serialized into the session, not good at all.
Another somewhat confusing aspects on @Persist on a component is that if
the same object/value was @Persist-ed in different components it would be
stored multiple times in the session, once for each component (class or
instance, I'm still not sure) that had an @Persist.
Since you mentioned you do have a few cases where you do use @Persist in
your application - can you dig up a few examples that seem like good
examples of when you do use them ?
Cheers - Alex K
On Thu, Jan 3, 2013 at 12:48 PM, Taha Siddiqi <tawus.tapes...@gmail.com>wrote:
> 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
>
>
