> > I was thinking of having iterator(int first, int count, DataView
> > dataView) which would eliminate the requirement for keeping
> state in
> > the dataprovider and still let you work directly off the interface.
>
> Are you looking to have these DataProviders be singletons?
> That could make your getModel(Object) method tricky to
> implement. I've gotten
> Hibernate3 to work like that, but the EJB3 spec doesn't
> provide any way to get metadata for a given object (primay
> key field, classname if it's proxied, etc).
No, dataproviders don't have to be singletons, what I meant is that I would
like to keep it simple enough where you can code directly to the interface
instead of having to start with an abstract class if you don't need the
complexity. In fact I was thinking using the data provider to store sorting
and filters - seems like a natural place. Also I was going to have a
separate data provider for each situation so the model resolution can be
done there. In my case I am using ejb3 and don't want the data provider to
have access to entitymanager directly, so I cannot write a generic data
provider based on the class name of the entity - this also means I cannot
have a generic detachable model. If you want a generic dataprovider based on
entity class name you can implement that yourself.
> > Currently I call removeAll() every request, your data can change at
> > any point w/out you knowing (new row gets inserted that would be in
> > the middle of listview). This can be fixed by letting the user
> > override the id for the listitem - setting it to the pk of
> the object.
> > That way we can keep a list of listitems not rendered
> during the request and delete them at the end.
> > Does this sound like it would work? If so I will implement it.
>
> Removing all on every request doesn't let you store any state
> across requests (like with forms), so you can't do that all
> the time. I like the idea of dropping and rerendering only
> items that need it, though I don't think using the ID is
> going to work. For one it's read only, and it also needs to
> have an eqivilent entry in the HTML. You could always just
> add a field to the item for the key.
You misunderstood. Look in ListView.newItem(int idx). Currently its taking
an index and bases the id on that. This is obviously not going to work if
you want to keep listitems across requests. So maybe what we need to do is
change that to
DataView.newItem(String id) - the id is a string rep of the objects pk.
So we can either add String primaryKey(Object o) in the data provider or
introduce a new inteface
IPrimaryKeyProvider { String primaryKey(Object o); } and in dataview we can
do:
If (dataprovider instanceof IPrimaryKeyProvider) {
use pk id
} else {
use index based id
}
Not sure what the best route is.
Igor
-------------------------------------------------------
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
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
