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 call to “getModelObject()” inside my components with a try-catch (so in methods like onConfigure, onClick etc). Met vriendelijke groet, Kind regards, Bas Gooren Op 14 januari 2021 bij 19:18:57, Sven Meier (s...@meiers.net) schreef: 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
