Hi, You might be interested in this discussion: http://markmail.org/message/qttwc5kunubl6ieo
Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Feb 19, 2016 at 7:19 PM, Francois Meillet < [email protected]> wrote: > 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 <[email protected]> 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 ([email protected]) > 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: [email protected] > > For additional commands, e-mail: [email protected] > > > >
