Got it. Thank you for taking the time to lay it all out for me. -Phil
On 6/19/05, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > Phil Kulak wrote: > > >It does, thank you. But in your example, won't the model object be a > >list, not the actual object? And if it is the object, wouldn't it be > >the wrong object if the underlying datastore had changed between > >requests? > > > > > In my example there are two things to notice: > 1. the button/link is added to the ListItem, not the ListView > 2. the onClick is executed some time after the render, in a new RequestCycle > > due to 1., the model object I ask for in the onClick() with > 'getParent().getModelObject()' will be the object pointed to by the > ListItem model, and that will be item X. Due to 2, it is usually not > possible to use a direct reference to the object, bound at render time. > Using getParent().getModelObject() allows Wicket to re-wire the model > (list and elements). > > As for it being the wrong object, that is true, given that the default > List model uses the index of the objects in the list (0, 1, 2, 3, 4, > etc) to resolve elements. The ListView I believe allows you to override > model object creation, in order to allow you to use for example the > primary key as an index. Look at ListView.getListItemModel(IModel, > index) > (http://wicket.sourceforge.net/apidocs/wicket/markup/html/list/ListView.html#getListItemModel(wicket.model.IModel,%20int)) > for more information. > But this is always a concern when doing multi user application > programming, not a specific Wicket one ;-). The only solution I can see > which may solve the changed elements of the list problem is to store the > list and all elements in the session and reuse that when the request is > handled. For fairly long lists this will become a memory and scalability > concern. But it won't account for objects that have been deleted by > other users during the rendering of the page and the handling of the > request. The object will still be in your session stored list, but when > you want to perform some action on it, your persistence layer will be > unable to find the original object. > > Martijn > > >-Phil > > > >On 6/19/05, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > > > > >>Phil Kulak wrote: > >> > >> > >> > >>>So, as long as I don't make something final, am I alright? > >>> > >>> > >>> > >>That was not what I meant. When you make things final, you keep > >>references to those objects. You can make things final, but you /really/ > >>need to know what will happen then. > >> > >> > >> > >>>For > >>>example, how about not using an inner class: > >>> > >>>final PageableListView list = new PageableListView("rows", data, 10) > >>>{ > >>> public void populateItem(ListItem listItem) > >>> { > >>> MyObject value = (MyObject) listItem.getModelObject(); > >>> listItem.add(new Label("name", value.getName())); > >>> } > >>>}; > >>> > >>>It looks to me here like the reference to the "name" String will live > >>>on between requests, but that the object itself and all other > >>>properties should get garbage collected. Is that right? > >>> > >>> > >>> > >>> > >>True, but that was not your question. You tried to use one instance of > >>an object both at render time and when the request is processed. > >>The problem /may/ arrize when you have different moments of refering to > >>the objects (i.e. storing references to them during render time and > >>using those when the request gets handled) or when you use > >>REDIRECT_TO_RENDER. Using Hibernate you may experience objects that > >>aren't attached to a Hibernate session. > >> > >>If you keep a 'hard' reference to the objects, they won't get attached > >>when handling the request. So you have to use the getModelObject() > >>method to retrieve the object. This will attach the model, and give you > >>the correct object (fresh from the database). > >> > >>I hope I make some sense to you. > >> > >>Martijn > >> > >> > >> > >>>On 6/19/05, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>> > >>> > >>>>The problem is that populateItem() is called at render time, and that > >>>>the onClick() is called when you have been to the client and are > >>>>processing the component listener. I have falled into this trap myself, > >>>>and I can only advise you to use the following code, which is a lot more > >>>>safer in any context: > >>>> > >>>>final PageableListView list = new PageableListView("rows", data, 10) > >>>>{ > >>>> public void populateItem(ListItem listItem) > >>>> { > >>>> listItem.add(new Link("sjs") { > >>>> public void onClick() { > >>>> MyObject value = (MyObject) getParent().getModelObject(); > >>>> System.out.println(value.getName()); > >>>> } > >>>> } > >>>>}; > >>>> > >>>>Note that all final keywords have disappeared and no hidden magic is > >>>>remaining on keeping references to object between render and handling > >>>>time. > >>>> > >>>>Martijn > >>>> > >>>> > >>>>Phil Kulak wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Maybe it's just late, but I can't seem to answer this question myself. > >>>>>Will each model object in my list exist after the request has finished > >>>>>with the following code, assuming that the list is wrapped in a > >>>>>detachable model: > >>>>> > >>>>>final PageableListView list = new PageableListView("rows", data, 10) > >>>>>{ > >>>>> public void populateItem(final ListItem listItem) > >>>>> { > >>>>> final MyObject value = (MyObject) > >>>>> listItem.getModelObject(); > >>>>> listItem.add(new Link("sjs") { > >>>>> public void onClick() { > >>>>> > >>>>> System.out.println(value.getName()); > >>>>> } > >>>>> }); > >>>>> } > >>>>>}; > >>>>> > >>>>>or how about this: > >>>>> > >>>>>final PageableListView list = new PageableListView("rows", data, 10) > >>>>>{ > >>>>> public void populateItem(final ListItem listItem) > >>>>> { > >>>>> final MyObject value = (MyObject) > >>>>> listItem.getModelObject(); > >>>>> final String name = value.getName(); > >>>>> > >>>>> listItem.add(new Link("sjs") { > >>>>> public void onClick() { > >>>>> System.out.println(name); > >>>>> } > >>>>> }); > >>>>> } > >>>>>}; > >>>>> > >>>>> > >>>>>------------------------------------ ------------------- > >>>>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>from IBM. Find simple to follow Roadmaps, straightforward articles, > >>>> > >>>> > >>>> > >>>> > >>>>>informative Webcasts and more! Get everything you need to get up to > >>>>>speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click > >>>>>_______________________________________________ > >>>>>Wicket-user mailing list > >>>>>[email protected] > >>>>>https://lists.sourceforge.net/lists/listinfo/wicket-user > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>------------------------------------------------------- > >>>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > >>>> > >>>> > >>>>from IBM. Find simple to follow Roadmaps, straightforward articles, > >>> > >>> > >>>>informative Webcasts and more! Get everything you need to get up to > >>>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > >>>>_______________________________________________ > >>>>Wicket-user mailing list > >>>>[email protected] > >>>>https://lists.sourceforge.net/lists/listinfo/wicket-user > >>>> > >>>> > >>>> > >>>> > >>>> > >>>------------------------------------------------------- > >>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > >>> > >>> > >>>from IBM. Find simple to follow Roadmaps, straightforward articles, > >> > >> > >>>informative Webcasts and more! Get everything you need to get up to > >>>speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click > >>>_______________________________________________ > >>>Wicket-user mailing list > >>>[email protected] > >>>https://lists.sourceforge.net/lists/listinfo/wicket-user > >>> > >>> > >>> > >>> > >> > >>------------------------------------------------------- > >>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > >>from IBM. Find simple to follow Roadmaps, straightforward articles, > >>informative Webcasts and more! Get everything you need to get up to > >>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > >>_______________________________________________ > >>Wicket-user mailing list > >>[email protected] > >>https://lists.sourceforge.net/lists/listinfo/wicket-user > >> > >> > >> > > > > > >------------------------------------------------------- > >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > >from IBM. Find simple to follow Roadmaps, straightforward articles, > >informative Webcasts and more! Get everything you need to get up to > >speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click > >_______________________________________________ > >Wicket-user mailing list > >[email protected] > >https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Wicket-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-user > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
