a simple example of ondetach necessity, lets say you have a component that
uses more then one imodel to get data (just like listview)
public class MyComponent extends Component {
private final IModel model2;
public MyComponent(String id, IModel model1, IModel model2) {
super(id, model1);
this.model2=model2;
}
public void onDetach() {
// model1 is taken care of because it is the component model, but not
model2
model2.detach();
}
}
-igor
On 1/5/07, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
ok, were equal on onAttach -
for onDetach: ok I think I understand the problem here - you might have a
component that is accessed in more than 1 request and could hold resources
in it for its livetime - Did I get it right here ?
> -----Ursprüngliche Nachricht-----
> Von: Matej Knopp [mailto:[EMAIL PROTECTED]
> Gesendet: Freitag, 5. Januar 2007 11:28
> An: [email protected]
> Betreff: Re: AW: AW: AW: another big 2.0 refactor
>
> I can't give you example for onAttach, because I don't think
> we really need it.
>
> onDetach is different. onDetach calls the detaching methods
> on model and behavior. And the component can have more state
> than just model (and behaviors). If you components don't
> that's fine. But it doesn't mean that other components don't
> need it. In the tree for example there is lot of processing
> during the request, with objects that are temporary and span
> during the request. But they are not needed after the request
> is processed, so they are cleaned in onDetach.
>
> -Matej
>
> Korbinian Bachl wrote:
> >> I'm in contact with garbage collection every time i make a
> reference
> >> to an object. With web applications you have to think of object
> >> instance lifecycle even more, otherwise you can easily end
> with bad
> >> performance or memory leaks. Yes, memory leaks. It's not that
> >> difficult to make application in java that leaks memory.
> >
> > sad but true :/ - however, compared to C/C++ its much better now ;)
> >
> >> If you use proper model, you (as user) will never have to
> deal with
> >> Component.onDetach directly. But if you allocated something during
> >> request and want to clean it afterwards, onDetach is the
> place to do
> >> that.
> >
> > thats the point - if you do things right, you wont need it - if you
> > have big lists/ special coneections to resources etc. then a
> > LoadableDetachableModel is way to go, and i prefer plain
> easy ways, as
> > i usually end up in a mess when i try to make things too
> complicated -
> > and you still have 2 steps in my point of view - before and
> > afterRender IMHO: these 5 steps are enough as long as you
> use proper
> > connect on resource and would force users to do it the only
> possible
> > way: the right one
> >
> > Or can you give me 1 example where i really need onAttach onDetach
> > that cant be solved using LoadAble/Detachable Models ?
> >
> > Regards
> >
> > PS: sorry for half-post before :(
> >
> >
> >> -Mate
> >>
> >> Korbinian Bachl wrote:
> >>> Internally yes - but why does the user have to get in
> contact? - i
> >>> mean, have you ever been in contact directly with the garbage
> >>> collection? - everything that may be needed could be at
> >> onAfterRender
> >>> so instead of:
> >>>>>> 1) resolve link component
> >>>>>> 2) invoke onattach
> >>>>>> 3) invoke onclick
> >>>>>> 4) invoke onbeforerender
> >>>>>> 5) invoke render
> >>>>>> 6) invoke onafterrender
> >>>>>> 7) invoke ondetach
> >>> this should be enough (IMHO):
> >>>
> >>>
> >>>
> >>>> -----Ursprüngliche Nachricht-----
> >>>> Von: Matej Knopp [mailto:[EMAIL PROTECTED]
> >>>> Gesendet: Freitag, 5. Januar 2007 10:56
> >>>> An: [email protected]
> >>>> Betreff: Re: AW: another big 2.0 refactor
> >>>>
> >>>> Are you serious? The whole point of garbage collector is that it
> >>>> collects unreferenced object instances. And the point of
> >> detaching is
> >>>> cleaning references so that objects can be garbage collected.
> >>>>
> >>>> -Matej
> >>>>
> >>>> Korbinian Bachl wrote:
> >>>>> Hi Igor,
> >>>>>
> >>>>> i still dont see the usecase here - neither for onAttach
> >>>> nor for onDetach.
> >>>>> You know why? - I went for Java because i hate to have
> >> Objects with
> >>>>> Destructors, i hate superloaded constructors where 90% of
> >>>> the code is
> >>>>> just to make sure the things we need are here - i hate
> >> pointers - i
> >>>>> love garbage collection, i like simple objects, i like big
> >>>> units done in capable steps...
> >>>>> well, this onAttach/ onDetach seems for me as bringing a
> >>>> C/C++ problem
> >>>>> back into the java world - if we need a resource, just use
> >>>> it, and let
> >>>>> the resource decide if its ready or not and handle that - and
> >>>>> onDetach: sun "invented" GarbageCollection to get rid if
> >>>> this in Java,
> >>>>> and we bring it back in now?
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>> Korbinian
> >>>>>
> >>>>>
> >>>>>> -----Ursprüngliche Nachricht-----
> >>>>>> Von: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> >>>>>> Gesendet: Freitag, 5. Januar 2007 02:30
> >>>>>> An: [email protected]
> >>>>>> Betreff: another big 2.0 refactor
> >>>>>>
> >>>>>> ive been discussing with johan offline, and here is what
> >>>> we came up
> >>>>>> with
> >>>>>>
> >>>>>> there is still a big onattach refactor to do in 2.0. big
> >>>> meaning it
> >>>>>> will affect a lot of users.
> >>>>>>
> >>>>>> the contract for onattach/ondetach was that these methods
> >>>> are called
> >>>>>> before the framework executes any method on the component,
> >>>> but right
> >>>>>> now onattach is pretty much onbeginrender with the
> >>>> exception that you
> >>>>>> are allowed to modify the component hieararchy.
> >>>>>>
> >>>>>> take a simple case of clicking link.
> >>>>>>
> >>>>>> the story should be:
> >>>>>>
> >>>>>> currently it is
> >>>>>>
> >>>>>> 1) resolve link component
> >>>>>> 2) invoke onclick
> >>>>>> 3) invoke onattach
> >>>>>> 4) invoke onbeforerender
> >>>>>> 5) invoke render
> >>>>>> 6) invoke onafterrender
> >>>>>> 7) invoke ondetach
> >>>>>>
> >>>>>> but should be
> >>>>>>
> >>>>>> 1) resolve link component
> >>>>>> 2) invoke onattach
> >>>>>> 3) invoke onclick
> >>>>>> 4) invoke onbeforerender
> >>>>>> 5) invoke render
> >>>>>> 6) invoke onafterrender
> >>>>>> 7) invoke ondetach
> >>>>>>
> >>>>>> notice 2 and 3 are reversed as per contract of onattach
> >>>> but there is
> >>>>>> a problem with this. suppose link has a compound model,
> >> and inside
> >>>>>> the link you call getmodelobject() since the model belongs
> >>>> to link's
> >>>>>> parent shouldnt link parent's onattach be called as well? the
> >>>>>> contract says so.
> >>>>>>
> >>>>>> the only way to guarantee onattach contract is to alter
> >> the event
> >>>>>> chain to this
> >>>>>>
> >>>>>> 1) resolve link component
> >>>>>> 2) invoke page.onattach
> >>>>>> 3) invoke onclick
> >>>>>> 4) invoke onbeforerender
> >>>>>> 5) invoke render
> >>>>>> 6) invoke onafterrender
> >>>>>> 7) invoke page.ondetach
> >>>>>>
> >>>>>> this means that all code that is in onattach needs to move to
> >>>>>> onbeforerender and onbeforerender needs to be relaxed to allow
> >>>>>> changes in the component hierarchy, while onattach should
> >>>> not allow
> >>>>>> modification of hierarchy. this restriction is
> necessary so, for
> >>>>>> example, link's parent doesnt remove the link before
> onclick is
> >>>>>> invoked on it.
> >>>>>>
> >>>>>> invocation chain for a page set into the request cycle via
> >>>>>> setresponsepage() would be the same but with step 3 taken out.
> >>>>>>
> >>>>>> the refactor itself will be pretty easy make
> >>>> onbeforerender final -
> >>>>>> this will make all overrides visible move code from
> overrides to
> >>>>>> onattach delete onbeforerender rename onattach to
> onbeforerender
> >>>>>> create new onattach
> >>>>>>
> >>>>>>
> >>>>>> thoughts?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> -igor
> >>>>>>
> >>>
> >>
> >
> >
>
>
