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 > >>>> > >>> > >> > > > > > >
