I think David may need to start from scratch...
First, render a page with no errors. The template can include a zone. Notice
that the zone is rendered too. It defines an area that the server can now
refresh - but only in response to an AJAX request.
You can set up the fields on before you render it or during render. In your
example, you're setting up the fields during render. This happens in the
sequence that they're referenced in the template. isError and errorMessage are
referenced before myValue, so they are false and empty because getMyValue has
not been called yet. A solution is to set them up before render, use
setupRender(). For example, you could do this:
private String myValue;
void setupRender() {
setupMyValue();
}
private void setupMyValue() {
// ... do it and set errors if necessary.
}
public String getMyValue() {
return myValue;
}
...or in the style I prefer...
@Property
private String myValue;
void setupRender() {
setupMyValue();
}
private void setupMyValue() {
// ... do it and set errors if necessary.
}
Now you'll see your errors and your value. You could remove the zone (but not
its contents) and the effect will be the same. The zone is only useful if, now
that the page has been rendered and returned to the browser, you need to send
an AJAX request and have a partial-page response.
HTH,
Geoff
On 27/03/2014, at 5:49 AM, Thiago H de Paula Figueiredo wrote:
> On Wed, 26 Mar 2014 10:44:05 -0300, Davide Vecchi <[email protected]> wrote:
>
>>> Anyway, maybe you should rethink the way you handle your exceptions.
>>> Shouldn't they be treated inside the getter methods themselves?
>>
>> I'm very confused about this suggestion. Am I not doing exactly that ? I
>> mean, treating the exception inside the getter is exactly what I was trying
>> to do in the first place, by showing an error message, which turned out not
>> to be possible,
>
> It's not possible because the error message is rendered before the getter is
> called.
>
>> So I will just call the getters from setupRender(). I'm a bit perplexed
>> going for something that sounds a bit like a workaround for a scenario that
>> in my opinion is quite standard, but maybe I will come up with something
>> more straightforward in future.
>
> That's not a workaround, it's a matter of what is called first.
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> 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]
