Re: Checking preconditions/changes in models

[Sven Meier]

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.


Regretfully I don't have any code for that available any longer :(

Have fun
Sven



On 29.01.21 14:55, Bas Gooren wrote:

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 behavior to those components, and a page-level 
behavior as “catch-all” for normal render requests?
(Since the catch-all behavior on the page will not catch exceptions 
that occur when only a subtree of the page is rendered)
The thread local is probably to store the component + exception, so 
the listener can access it?


Are you able to share some (stripped down) code of the request cycle 
listener?


I all the non-trivial apps that I’ve built in wicket, exception 
handling always becomes an issue at some point.
There’s not much documentation on this besides catching all exceptions 
and displaying an error page.


So I’d like to take a stab at rolling a wicketstuff project for this, 
so others can use it (or learn from it) :-)


Met vriendelijke groet,
Kind regards,

Bas

Op 20 januari 2021 bij 11:06:13, Sven Meier (s...@meiers.net 
) schreef:



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 
) 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 

Re: Checking preconditions/changes in models

[Bas Gooren]

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 behavior to those components, and a page-level behavior
as “catch-all” for normal render requests?
(Since the catch-all behavior on the page will not catch exceptions that
occur when only a subtree of the page is rendered)
The thread local is probably to store the component + exception, so the
listener can access it?

Are you able to share some (stripped down) code of the request cycle
listener?

I all the non-trivial apps that I’ve built in wicket, exception handling
always becomes an issue at some point.
There’s not much documentation on this besides catching all exceptions and
displaying an error page.

So I’d like to take a stab at rolling a wicketstuff project for this, so
others can use it (or learn from it) :-)

Met vriendelijke groet,
Kind regards,

Bas

Op 20 januari 2021 bij 11:06:13, Sven Meier (s...@meiers.net) schreef:

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) 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
>> 

Re: Checking preconditions/changes in models

[Sven Meier]

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) 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



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Checking preconditions/changes in models

[Bas Gooren]

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

Re: Checking preconditions/changes in models

[Sven Meier]

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