You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Tobias Wehrum <Le...@dragonlab.de> on 2009/04/22 23:15:13 UTC
Re: [T5] Persistent fields may not be updated until after the page
has finished loading
Does that mean that for every persistent variable you have to write a
if (field == null) field = new Anything();
in the SetupRender? Is there no easier way?
Cheers,
Tobias
Marcel Sammut schrieb:
> 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.
>
> 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,
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Persistent fields may not be updated until after the page
has finished loading
Posted by Felix Gonschorek <fe...@gg-media.biz>.
My suggestion: care for the initialization in the getters - this works best for
me. Like this:
public MyBusinessBean getBean() {
if (this.bean == null) {
this.bean = new MyBusinessBean();
}
return this.bean;
}
works for pages and components... (onActivate!!)
Felix
Tobias Wehrum schrieb:
> Does that mean that for every persistent variable you have to write a
>
> if (field == null) field = new Anything();
>
> in the SetupRender? Is there no easier way?
>
> Cheers,
> Tobias
>
> Marcel Sammut schrieb:
>> 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.
>>
>> 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,
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
--
Felix Gonschorek
GG-Media
Kirchstr. 18
69115 Heidelberg
Tel: +49 6221 890 168-0
Fax: +49 6221 890 168-1
Mobil: +49 176 2234 1338
felix@gg-media.biz
http://www.gg-media.biz
Vertretungsberechtigte Gesellschafter:
Felix Gonschorek & Jochen Greiner
Umsatzsteuer-Identifikationsnummer
gemäß § 27a Umsatzsteuergesetz:
DE232906440
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org