> I'm not sure if this is still a debate. but I really like
> keeping ListView and PageableListView's model plain old
> lists.
We are not changing the framework, we are working on additional components.
I like the dataprovider interface because it is much more low level then the
general list interface.
> 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.
Unfortunately the only object that knows exactly how the paging should be
set up is the listview and not the dao. How does your dao know the exact
window size? If your window is too small you are issuing multiple queries,
if your window is too big you are getting more than you need which is a
waste of memory. In my app the user can change the size of any listview and
it was a pain to keep maintaing paged list window size.
With this interface its transparent because you are getting all information
you need with every request.
>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.
I agree, it has an air of a more elegant approach, but there are a lot of
caveats. What if someone tries to sort the list using Collections? Are you
going to bring in 10000 rows with a window size of 20? Its too easy to do
something like that, there is no way to know where the list comes from.
Igor
>
> 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
>
>
>
-------------------------------------------------------
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
