Hi Bas,
> The thread local is probably to store the component + exception, so
the listener can access it?
yes, it allows the exception handler to identify the when and where of a
problem. A redirect to a full page render is possible, after
removing/replacing the offending component.
Regret
Hi Sven,
Thank you for explaining in detail, it helps a lot :-)
Part of your steps I have already implemented, but I never thought about
marking optional components or relying on Behavior#onException.
Since some components can be replaced in AJAX request, I guess you add an
exception-catching be
Hi Bas,
>E.g. do you handle exceptions within the model itself, or with a
RequestCycleListener?
a requestCycleListener is my preferred solution:
- I've used Spring interceptors to wrap all exceptions from the service
layer for easier identification of the origin of the problem
- check the c
Hi Sven,
Thank you for your reply.
On catching failure “when it happens”: can you explain what that looks like
for you?
E.g. do you handle exceptions within the model itself, or with a
RequestCycleListener?
I think the tricky part is handling exceptions thrown by models, unless I
guard every ca
Hi Bas,
in my experience is is very hard to check every possible failure upfront
in preconditions (whether from page or models). There's always a
corner-case waiting to hunt you.
Therefore I prefer using option 1: catch the failure when it happens.
Worked fine for me (most of the time), but m
Hi all,
First off: best wishes to everyone for 2021, and that we may all have fun
this year building stuff in Wicket!
I’m wondering how others implement the following requirement…
Suppose a page has a model backed by something stored in the session or
database (e.g. an e-commerce basket page or