Thanks for the pointers about onException and @Cached, I didn't know either.
@Cached would allow me to avoid wrapping the getter body in an "if (this.myValue == null)". onException would help my case only if it was possible to update a zone from that method even if the exception that triggered its execution had occurred in a getter called during page rendering, which I imagine is not possible, but I will check. > 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, see my first example (it has no try/catch just because the error doesn't necessarily need to be a Java exception, it might be a call returning a value indicating failure or such). 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. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
