Well, I have never used prepareForRender(). I tend to have my pages
implement the pageBeginRenderListener interface or the
pageAttachListener interface. The former will cause a method called
pageBeginRender(IRequestCycle) to be called at the start of each
rendering of the page, much like prepareForRender. Within that
method, I know that the cycle parameter will return the correct value
for isRewinding(), so you can check whether you are at the start of
rewind cycle or a render cycle. I imagine that this is also true for
prepareForRender(). I could swear I remember reading something about
preferring pageBeginRender() over prepareForRender(), but I'm not
seeing it now, so maybe I was imagining things.
But it isn't quite as simple as merely choosing to only initialize
values before the rewind cycle but not before render, because when
your page is loaded via a link rather than a form submit, there will
be no rewind cycle, so you must do your initialization before the
render cycle instead. SO I have always done the following, in order
to be able to do initialization once per request, once for eachcycle,
or only for a particular cycle. I apply the following code to the
base page class for my application.
@InitialValue("ognl:false")
public abstract boolean isOnceInitialized();
public abstract void setOnceInitialized(boolean val);
public final void pageBeginRender(PageEvent event) {
initPage(event);
if (!isOnceInitialized()) {
initOnlyOnce(event);
setOnceInitialized(true);
}
if (getRequestCycle().isRewinding()) {
initForRewind(event);
} else {
initForRender(event);
}
}
// gets called before both rewind and render cycles
public void initPage(PageEvent event) {
}
public void initOnlyOnce(PageEvent event) {
}
// gets called before rewind cycle
public void initForRewind(PageEvent event) {
}
// gets called before render cycle
public void initForRender(PageEvent event) {
}
initPage gets called before every cycle, initOnlyOnce gets called only
once, no matter whether there is a rewind cycle or not. The other two
are self explanatory.
In the future I might see if I can overload the behaviour of the
object which controls the rendering of a page (the engine? I haven't
looked into it) in order to test for interfaces specific to each of
the 4 possible init phases, rather than overloading pageBeginRender,
so that I am not forced into a common base class. But this works
nicely, so far.
--sam
On 12/4/06, Skorpien126 <[EMAIL PROTECTED]> wrote:
Hmm yeah ... it´s doing something like this but I found no other way to make
the data persistent. My preparePage() looks like this...
public void prepareForRender(IRequestCycle request)
{
super.prepareForRender(request);
getPersistItem().reInit(this.getItem());
}
where PersistItem is the bean and Item the Object, holding the initial data.
Is there another way... I tried many ways but is the onliest one working.
Have someone a better way.... More infos what happening (which function
were) on validating could help.
P.S. THX for help.
Sam Gendler-2 wrote:
>
> I've never had this problem. When a form fails validation in my apps,
> I always see the content that was posted displayed back in the fields.
> Is it possible that the class which backs your page is initializing
> the bean back to default values after the rewind cycle completes with
> an error?
>
> --sam
>
>
> On 12/3/06, Skorpien126 <[EMAIL PROTECTED]> wrote:
>>
>> Ok... maybe I start nerving but I can´t belive that´s it not possible.
>>
>> The Situation: I have maybe 20 Textareas in a form... each one using the
>> "required" validator. The textareas are BOUND to a bean which has
>> lifecycle=Page. Reading and writing still works... but when I fill data
>> in
>> first 19 Textareas und I submit I get an ValidationError because the last
>> textarea has no text... so far so good, Validation is working.. but why
>> the
>> Hell it´s not possible to update the values. I can´t expire that my users
>> Refill all the textareas... Is there a workaround or so??? I read some
>> posts
>> refering this topic... but no REAL solution. Please help...
>>
>> --
>> View this message in context:
>>
http://www.nabble.com/Why-propertys-were-not-updated%2C-when-Form-%22hasErrors%22---tf2747592.html#a7665535
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Why-propertys-were-not-updated%2C-when-Form-%22hasErrors%22---tf2747592.html#a7686425
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
