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 maybe not a suitable approach
for all kind of applications.
Regards
Sven
On 12.01.21 14:37, Bas Gooren wrote:
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 checkout).
When the user opens multiple tabs (with different instances of the page),
either page can become “outdated” with regards to the actual data.
E.g. in Tab A the customer removes a product.
When the users then tries to update the quantity of that product in Tab B,
it can lead to a variety of runtime exceptions:
For example: Basket items are rendered with a repeater; If the # items in
the basket changes, rows may reference non-existant items (either by
database ID or by list index in the basket rows).
This sort of problem appears in various shapes and forms when a page
references data that may change independent from the page itself.
Over the years I have attempted to fix this in three ways:
1. Catch RTEs/Exceptions and re-render page (works OK); But suppose a
ListView is used, this also needs to handle things like
IndexOutOfBoundsException (thrown from inside ListItemModel) /
EntityNotFoundException / NullPointerException. Feels cluttered and
“cleaning up after the fact” instead of preventing the RTE in the first
place.
2. Check preconditions in page’s onConfigure(). Mixed results,
preconditions not always checked before action is executed (e.g. ajax link
click, form submit). So leads to finding more spots to check for
preconditions, e.g. Form#process
3. Wrap models with decorating models at the page level that check
preconditions; E.g. BasketNotEmptyModel; Usually combined with specialized
subclass of Form which manages transaction and commit/rollback
Of all these ways I prefer option 3 nowadays, as this is a close to the
“root” of the problem as possible: at the point where the data is accessed.
Since such models are always caching models (LDM), the overhead is minimal
(called once or twice per request).
Another advantage is that all components in the page point to the parent
model, which means preconditions are always checked for any component on
the page.
When using JPA we can even do a simple check for the entity “last modified”
or version, to ensure that the entity did not change between requests.
However, I’m evaluating which variant I will use from now on in projects
(to standardize) and am wondering how others handle this.
Any input/feedback is highly appreciated!
Kind regards,
Bas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
