Jan Blok wrote:
Hi,
Jan, please give me a good reason why ListModel is better
than AbstractList.
i can only see the downside of needing wrappers everywhere
for ListModel.
After some thought I think its just fine...java.util.List is a big
interface to implement if you are not using List, but from a wicket
point of view its good/complete/universal
as i've been trying to explain... this isn't true if you just use
AbstractList from the java collections package!
Ignore my last question in my previous mail I think I now understand
ListItem will not have an (public)index anymore (but holds-on to the
model and does a reverse modelobject index lookup to the List if it
wants the index for some reason, to overcome object index changes in the
List between detach and a new attach, correct?)
Jan
thoughts?
jon
Eelco Hillenius wrote:
So, first the removeAll on each request, and now the ListModel... I
argued about these things months ago!
Eelco
Jonathan Locke wrote:
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
-------------------------------------------------------
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
