yes, youre right - didnt take some things into account, sorry for that
> -----Ursprüngliche Nachricht-----
> Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> Gesendet: Freitag, 5. Januar 2007 11:42
> An: [email protected]
> Betreff: Re: AW: AW: another big 2.0 refactor
>
> When you use that loadabledetachablemodel .. when do you
> think onDetach() will be called on that model?
> ahh yes.. in the onDetach of the component. So we need this
> structure inside wicket thats what we are discussing here.
> You as a developer can override it if you want and do some
> extra detaching if you want.
> But for the normal things we need it our selfs so internally
> in wicket.
>
> johan
>
>
> On 1/5/07, Korbinian Bachl <[EMAIL PROTECTED]> 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
> > > >>>>
> > > >>>
> > > >>
> > > >
> > > >
> > >
> > >
> >
> >
>
