Yeah, IDetachable is better. Full graph traversal is only incrementally
worse that that required for serialization. It also happens after the
request.
A negative consideration: after making a change that requires components to
redetermine their models' cached states, it's nice to rely on direct calls
to Component#detach(). This proposal encourages a lazy style whereby
calling detach may not actually detach. Looking through core's and
extensions' detach() invocations, most appear unnecessary under this
proposal but I'm glad they're there for this reason.
On Fri, Apr 6, 2012 at 11:56 AM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote:
> its easy to enable detaching of any IDetachable field rather then only
> IModel. this code can also walk behaviors, but i dont think it should
> go beyond that. walking the entire object graph will be too expensive.
> right now it performs a lot of caching which makes it work well.
>
> -igor
>
> On Fri, Apr 6, 2012 at 10:48 AM, Dan Retzlaff <dretzl...@gmail.com> wrote:
> > Sorry to double-post, but I realized it's trivial to visit the object
> graph
> > since local final variables show up as fields in the inner class. This
> > following snippet prints "detaching". So what do you think about
> > generalizing the automatic detach to all objects, not just components?
> >
> > final IModel model = new IModel() {
> > @Override
> > public Object getObject() {
> > return null;
> > }
> > @Override
> > public void setObject(Object object) {
> > }
> > @Override
> > public void detach() {
> > System.out.println("detaching");
> > }
> > };
> > Object object = new Object() {
> > public void method() {
> > System.out.println(model.getObject());
> > }
> > };
> > for (Field f : object.getClass().getDeclaredFields()) {
> > System.out.println(f.getName());
> > if (IModel.class.isAssignableFrom(f.getType())) {
> > f.setAccessible(true);
> > ((IModel)f.get(object)).detach();
> > }
> > }
> >
> > On Fri, Apr 6, 2012 at 11:26 AM, Dan Retzlaff <dretzl...@gmail.com>
> wrote:
> >
> >> I wish there were a way to apply this strategy to the whole object graph
> >> (not just fields). I use local final LoadableDetachableModels on
> occasion,
> >> and it'd be nice for those to magically detach too. I'm +0.
> >>
> >> Just got Calc-Eric's message. Looks like we're on the same page.
> >>
> >>
> >> On Fri, Apr 6, 2012 at 10:42 AM, Igor Vaynberg <igor.vaynb...@gmail.com
> >wrote:
> >>
> >>> i wrote a IDetachListener that automatically detaches any IModel
> >>> fields found on components. is this something we would be interested
> >>> in for core? its been running in production for a while without any
> >>> noticeable overhead and its nice not to have to implemenet onDetach()
> >>> all the time just to forward it to secondary models. the only downside
> >>> is that once we introduce this feature we can never remote it because
> >>> doing so will break code.
> >>>
> >>> thoughts?
> >>>
> >>> -igor
> >>>
> >>
> >>
>
