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 current handler to differentiate between actions or
rendering
- in case of actions check targeted component (e.g. use annotations to
mark optional components)
- in case of rendering you can identify the failing component with
Behavior#onException() (utilizing a ThreadLocal)
- inspect the stacktrace as last resort
- re-render the page and show a feedback message
Regards
Sven
On 20.01.21 09:18, Bas Gooren wrote:
> 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
<mailto: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
<mailto:users-unsubscr...@wicket.apache.org>
> For additional commands, e-mail: users-h...@wicket.apache.org
<mailto:users-h...@wicket.apache.org>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
<mailto:users-unsubscr...@wicket.apache.org>
For additional commands, e-mail: users-h...@wicket.apache.org
<mailto:users-h...@wicket.apache.org>