I'm not sure if this is still a debate. but I really like keeping
ListView and PageableListView's model plain old lists. It's just as
easy to build paging into a List as it is into the component itself.
However, the way it is currently, my DAO can return a paging list and
set up exactly how said List gets it's data each time it pages;
exactly what a DAO is supposed to do. And even though the list has a
bunch of extra features for paging, sorting, or whatever, it's still a
list, which is what you expect to get back when you call a method like
findAll(). The way it's set up now is just a lovely way to separate
the data access from components.
On 7/27/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > Why not have
> >
> > public interface DataProvider extends Serializable {
> >
> > Iterator getElements(int first, int minCount);
> > int getCount();
> > }
> >
>
> I was definetely thinking of doing that, didn't get to it yet. A list was
> simply the most convinient because that's what EntityManager returns and I
> didn't have to rewrite too much existing listview code. As I said this was
> just a proof-of-concept to test the interface idea.
>
> Maybe one of the wicket devels can create a project for us in one of the
> subprojects and we can collaborate if you are interested.
>
> > If you have a List you have an Iterator and an Iterator will
> > work for any Collection (and more). I think minCount should
> > tell just the minimum number of elements the iterator should
> > contain. This is just to get it easy and cheap from a List.
> > (Maybe alternatively it could also be just a hint so that the
> > iterator could actually be smaller).
>
> If I understand you correctly you would like to provide the min amount of
> entries and have the iterator access more if they are needed? If so, this is
> one of the things I was trying to eliminate. Currently dataview asks your
> dataprovider for the exact segment of data it needs and so it eliminates the
> whole need for retrieving data window by window.
> If you want to connect a list all you have to do is list.sublist(first,
> first+count).iterator()
>
> > Maybe keep the Object to IModel translation in the DataView
> > (ListView) - I have to extend it anyway. In case it is a
> > horizontal concern, you could easaly write a delegating
> > Iterator: (and plug it in whereever you need it)
> >
> > public class ModelIterator implements Iterator{
> > private Iterator _delegate;
> > public boolean hasNext(){
> > return _delegate.hasNext();
> > }
> > public Object next(){
> > return makeIModel(_delegate.next());
> > }
> > ......
> > }
>
> In order to achieve this the default impl of getlistitemmodel() in the
> dataview would have to pass the object through unchanged. Is that what you
> are thinking?
>
> Also, where would be a good point to wrap the iterator? I will have to play
> with this tomorrow to see. Let me know if you have any ideas.
>
> Igor
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO September
> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
