Very interesting discussion. Yes I agree, IDetachListener should only be used as a checker in dev.
François Le 20 févr. 2016 à 12:54, Martin Grigorov <mgrigo...@apache.org> a écrit : > 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 < > francois.meil...@gmail.com> 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 <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 >>> >> >>