Thanks for your reply. I have a follow up question:
For @Persist field, when and how does variable binding (from HTTP
session-cached value) happen?
Let me explain:
Previously, when I use inline (or constructor-based) variable
initialization, although I don't know how the magic works, I am guaranteed
that only the first time a component/page object is instantiated, the
@Persist field is populated with the initial value. Subsequently when the
component/page object is retrieved from the object pool and re-used, it is
not the initial value, but the session-cached value, that is associated with
the variable. This is important because the field value might have changed
due to user action between the object instantiation and re-use.
If I have to assign value explicitly in @SetupRender, since that method is
always called by Tapestry whether this is a new or re-used object instance,
to ensure the session-cached value is bound to the filed, do I have to do
(can we assume this is how T5 actually work behind the scene)?
@SetupRender () {
void initializeField() {
if(session.getAttribute("persistedFieldName") == null) {
myPersistedField = "some initial value";
}
}
, which has 2 major problems:
1. I have to touch HttpSession, something that T5 makes every effort to hide
from me.
2. Can I assume the session key is actually the session key. What if the T5
internal implementation changes tomorrow?
Marcel Sammut wrote:
>
> I had the same problem when moving to 5.0.16. It was pretty simple for
> me, since what I was doing was initializing my persistant variables in the
> declaration. What I did was move the initialization to the SetupRender
> phase of the cycle.
>
> For example:
> @Persist
> private int count = 0;
>
> became:
> @Persist
> private int count;
> @SetupRender
> void setupRender() {
> count = 0;
> }
>
> Hope that works for you too.
> Cheers,
> Marcel
>
>
> Eric Ma wrote:
>>
>> Why was this restriction introduced in 5.0.16? It completely breaks our
>> application. If the benefit is marginal, can we roll back to the
>> original behavior? Or alternatively, what is a "better" practice under
>> 5.0.16?
>>
>> Thanks,
>>
>
>
--
View this message in context:
http://www.nabble.com/-T5--Persistent-fields-may-not-be-updated-until-after-the-page-has-finished-loading-tp20587662p20628995.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
