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. 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. 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. i had a really satisfactory talk with chris about versioning 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... 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

Reply via email to