Detachable Models best practices

[Neil Curzon]

Hi all,

Using 1.3.6, I've recently been simplifying some of my wicket code by using
LoadableDetachableModels and PropertyModels instead of trying to manage
static models in various ways.

I had a strange and subtle bug caused by the fact that a form button update
call into the next layer would take parameters such as the item id being
changed. To provide this item ID, I ended up resolving the model object,
which caused the LoadableDetachableModel to be loaded. The problem was that
this meant that the model was resolved before the update occurred, which
means that as the page was re rendered, the stale model object was used as
the source for the components. After the next update, the change made by the
previous update would be shown.

The ways that I can think of to fix this are 1. store the parameters needed
for the update call instead of using the model object to retrieve them or 2.
call detachModels on the component so that the models will be reloaded (kind
of crappy performance wise). But there will be no compile errors or runtime
warnings if I forget either of these, just a slightly stale view of the
page.

I'm worried that this bug will creep in again unless I can find a reliable
way to make sure that any updating event handlers can't accidentally load
the detachable model as they're updating. Has anybody found a good way to do
this?

Thanks
Neil

[Daniele Dellafiore]

I am not sure I completely understood what happens to you.
This sound to me like a problem I had in unit testing pages, when
calling, to say

tester.assertLabel

coused the model.getObject to be called and if model is a LDM, than it
results attached.
So I have to detach the component explicitly after.
Not beautiful, but is a problem I had only on the test side.

Now, maybe you can post some code to see when you occur to call
LDM.getObject during the update.
Sounds really strange to me that your id (the database id?) changes
during an update...

On Mon, Jun 29, 2009 at 6:05 PM, Neil Curzon<neil.curzon@...> wrote:

> Hi all,
>
> Using 1.3.6, I've recently been simplifying some of my wicket code by using
> LoadableDetachableModels and PropertyModels instead of trying to manage
> static models in various ways.
>
> I had a strange and subtle bug caused by the fact that a form button update
> call into the next layer would take parameters such as the item id being
> changed. To provide this item ID, I ended up resolving the model object,
> which caused the LoadableDetachableModel to be loaded. The problem was that
> this meant that the model was resolved before the update occurred, which
> means that as the page was re rendered, the stale model object was used as
> the source for the components. After the next update, the change made by the
> previous update would be shown.
>
> The ways that I can think of to fix this are 1. store the parameters needed
> for the update call instead of using the model object to retrieve them or 2.
> call detachModels on the component so that the models will be reloaded (kind
> of crappy performance wise). But there will be no compile errors or runtime
> warnings if I forget either of these, just a slightly stale view of the
> page.
>
> I'm worried that this bug will creep in again unless I can find a reliable
> way to make sure that any updating event handlers can't accidentally load
> the detachable model as they're updating. Has anybody found a good way to do
> this?
>
> Thanks
> Neil
>

--
Daniele Dellafiore
http://blog.ildella.net
http://twitter.com/ildella

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...