In my opinion never use @Persist in a reusable component. We have it in Grid
and it does create a problem when there are multiple grids on a page. Besides
you don't want a session at times and Grid doesn't help.
Pages can have @Persist e.g. you have a search page where you want the search
criteria to be persisted across requests. Or if you have a single page
application where you have a critical data you don't want to keep passing in
each request. Remember there are still ways to avoid them :)
But between ApplicationStateManager and context, i don't see much use cases.
regards
Taha
On Jan 4, 2013, at 1:43 AM, Cezary Biernacki wrote:
> On Thu, Jan 3, 2013 at 5:12 PM, Alex Kotchnev <akoch...@gmail.com> wrote:
>
>> 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
>> ?
>>
>
> See http://tapestry.apache.org/persistent-page-data.html:
>
> "A suitably long session attribute name is used; it incorporates the name
> of the page, the nested component id, and the name of the field."
>
> It means that every component instance has its own persisted values.
> However when one component instance is rendered multiple times
> (e.g. inside Loop or via repeated Delegate to the same Block),
> than the same set of persisted values is used.
>
> My rule of thumb regarding @Persist('session') fields:
> put them only in page classes or components
> that are supposed to be rendered only once per page (e.g. a layout
> component).
>
> Other components might access persisted data via parameter bindings.
>
> Best regards,
> Cezary
