You can also use a IDetachListener to check that no one LDM (field) is attached
after the page#detach() has been called.
In the Application#init() you can add
getFrameworkSettings().setDetachListener(
new IDetachListener() {
@Override
public void onDetach(Component component) {
for (Field field :
component.getClass().getDeclaredFields()) {
field.setAccessible(true);
Class<?> theClass = field.getType();
if
(LoadableDetachableModel.class.isAssignableFrom(theClass)) {
try {
if (((LoadableDetachableModel<?>)
field.get(component)).isAttached()) {
System.err.println("warning: component:" +
component.getClass().getName() + " / " + field.getName() + " is attached");
}
}
//
catch (IllegalAccessException e) {
e.printStackTrace();
}
}
}
}
@Override
public void onDestroyListener() {
}
}
);
François
Le 19 févr. 2016 à 16:47, Bas Gooren <b...@iswd.nl> a écrit :
> Hi,
>
> I think the only way to track this is with custom code (or with aspects for
> example).
>
> Since the contract of IModel only has detach() (and not isDetached()), this
> cannot be tracked easily.
>
> What I would do in such a case is probably to add a requestcyclelistener
> which walks a page after a request, iterates (/visits) over all the
> components and checks their models.
> Of course this requires the models to expose a way to check their status and
> origin.
>
> Also, what we do to prevent this: we have an abstract base model called a
> AbstractConversionModel<S,T> which takes a parent model (S) and converts to a
> target type (T), caching the conversion.
> This model takes a parent model as input (and subclasses of it require a java
> 8 Function<S,T> or expose an abstract method for the conversion etc).
> This model also takes care of detaching the parent model.
>
> In the end it’s all about education I guess: programmer’s should be careful
> when chaining models and ensure they detach the parent (/chained) model.
>
> Met vriendelijke groet,
> Kind regards,
>
> Bas
>
> Op 19 februari 2016 bij 15:41:03, gmparker2000 (greg.par...@brovada.com)
> schreef:
>
> Thanks for the reply. I suspect this is exactly the case we have created for
> ourselves. Although we have a good grasp on the detach process I suspect
> that there are places where this rule of thumb is not being followed.
> Although the example I gave is somewhat fictitious, any of the LDMs we have
> in our framework perform a detach on the parent. In the form there are
> numerous places where adhoc anonymous models are created and this is
> probably where the problems occur. Is there a recommended way to track
> these down? I ended up recompiling a version of Wicket with changes to
> LoadableDetachableModel that would essentially track every LDM within a
> RequestCycle. At the end of a request cycle I was left with a list of the
> models that never got detached. I also added a "whereAmI" member variable
> to LDM that would capture the stack trace in the constructor so I could
> figure out who instantiated the model in the first place.
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Wicket-model-problem-tp4673620p4673664.html
>
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
