Hi, > this is a good point and i think you're correct. the > downside is that > you'll have to wrap all your hibernate Lists in an adapter.
Well not every one is a hibernate user... Im not using hibernate > but it > still sounds good. we should also do this for trees. however, the > implementation you sketched wouldn't be the actual implementation > because the whole idea of using indexes is broken. Eh, I always try to go in small steps, small suggestions...the index was next on my list to address ... > i'd like to try to > address all this when i add our first implementation of versioning as > described on the list earlier. i hope to get to all of this before i > leave for holland. Holland? Servoy is located in holland (the netherlands) any change we could talk to you in person? :-) > i had a really satisfactory talk with chris about > versioning TIP use the word "revision" instead of "version", "version" is often confusing and mostly used to identify multiple items in a package: http://computing.ee.ethz.ch/sepp/cvs-1.10-to/cvsbook/main_11.html > and we both think what i sketched out on this list earlier is > actually really close to what we need... an implementation of page > versioning as a pluggable strategy. in order for this whole > scheme to > work though, components like ListView /must/ be resilient to > changes in > the model due to attach/detach. so indexes cannot work. we have to > actually hold onto the model that's in the list in our ListItem > implementation... So you are suggesting? something like: Public interface IListViewModel { public IModel getObjectAt(int index); ... Once retrieved you hold the model object? And not using ListItem.java any longer? Regards Jan > the only downside there is that you won't be able to > use the core listview if you actually care about indexes... the only > case i can think of where that would matter would be if you > had a list > with duplicate objects in it. behavior there would be an first or > all-or-nothing kind of thing. > > Jan Blok wrote: > > >Hi, > > > >Is there a reason to use a java.util.List interface in the > first place? > >Which is quite big to implement for many people, why not define an > >Interface alike javax.swing.ListModel? For example > > > >Public interface IListViewModel > >{ > > public Object getObjectAt(int index); > > public int getSize() > > //more needed? > >} > > > >I think many people have to put there own list objects in a > >(Lazy)ArrayList again...which they do already hold in (lazy loading) > >models. > > > >Regards Jan > > > > > > > > > >>-----Original Message----- > >>From: [EMAIL PROTECTED] > >>[mailto:[EMAIL PROTECTED] On Behalf > >>Of Eelco Hillenius > >>Sent: Tuesday, March 08, 2005 8:11 PM > >>To: [email protected] > >>Subject: Re: [Wicket-develop] should we make AbstractResource > >>serializeable or not? > >> > >> > >>We're in the process of reconsidering the ListView > >>implementation alltogether I think. > >> > >>If you really want this, you could provide a custom list that > >>does this. That list could lazily load it's size: when not > >>set yet, you load the actual list (e.g. from a database), but > >>when set, return it. And then the actual loading should occur > >>when one of it's accessor methods (like get(int) is called. > >> > >>E.g (haven't tested it, but the idea should work): > >> > >> > >>public class LazyList extends ArrayList > >>{ > >> private int size = -1; > >> > >> private boolean loaded = false; > >> > >> public LazyList(List list) > >> { > >> addAll(list); > >> } > >> > >> public int size() > >> { > >> if(size == -1) > >> { > >> load(); > >> this.size = super.size(); > >> } > >> } > >> > >> public get(int index) > >> { > >> load(); > >> return super.get(index); > >> } > >> > >> public void unload() > >> { > >> this.loaded = false; > >> } > >> > >> private void load() > >> { > >> if(!loaded) > >> { > >> this.loaded = true; > >> // do loading here and call super.addAll(..) > >> } > >> } > >> > >>.... etc .... > >> > >> > >>} > >> > >>and your model is like: > >> > >>public class MyModel extends AbstractDetachableModel > >> > >> private LazyList myList; // keep reference to list allways; > >>it'll usually be empty > >> > >> protected void onAttach() > >> { > >> if(myList == null) > >> { > >> myList = new LazyList(getSomeList()); > >> } > >> } > >> > >> protected void onDetach() > >> { > >> myList.unload(); > >> } > >> > >> protected Object onGetObject(Component component) > >> { > >> return myList; > >> } > >> > >>.... etc .... > >> > >> > >> > >>Btw, this might be a usefull pattern to either put on the > >>Wiki or in contrib. It's far more efficient for those cases > >>where you have a list that doesn't change over requests, are > >>that you want to 'push' the changes in, together with a > >>ListView that doesn't remove it's items on each request. > >> > >> > >>Eelco > >> > >> > >> > >>>It just happens that in my case - using a ListView - the > >>> > >>> > >>list view calls > >> > >> > >>>getModelObject within the onRender method (via getViewSize) > >>> > >>> > >>this is causing > >> > >> > >>>my detached model to re-attach for every request - even repeated > >>>IredirectListener requests. > >>> > >>>Could this component possibly be changed to remember the > >>> > >>> > >>size of the list ? > >> > >> > >>>Cameron > >>> > >>> > >>> > >>> > >>> > >> > >>------------------------------------------------------- > >>SF email is sponsored by - The IT Product Guide > >>Read honest & candid reviews on hundreds of IT Products from > >>real users. > >>Discover which products truly live up to the hype. Start > reading now. > >>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >>_______________________________________________ > >>Wicket-develop mailing list > >>[email protected] > >>https://lists.sourceforge.net/lists/listinfo/wicket-develop > >> > >> > >> > > > > > > > >------------------------------------------------------- > >SF email is sponsored by - The IT Product Guide > >Read honest & candid reviews on hundreds of IT Products from > real users. > >Discover which products truly live up to the hype. Start reading now. > >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >_______________________________________________ > >Wicket-develop mailing list > >[email protected] > >https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from > real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Wicket-develop mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-develop > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
