Who is defining how many rows that it should display?
The ListView (or what ever component) or the Navigator?
Because defining how many rows there are are useless if you don't attach
a paging component...
We could say that all these things can go into the navigator
then we also need 3 methods in IPageable.
setStartIndex(int index)
setRowCount(int count)
int getItemCount()
By default a IPageable has for start en row both -1 values and is
rendering all
This is just an idea of reversing the thing...
johan
Jonathan Locke wrote:
i'm starting a new email thread as the old one was getting really
really long!
what exactly is wrong with the earlier idea of just this?
public interface IPageable
{
public int getCurrentPage();
public void setCurrentPage(int);
public void getPageCount();
}
this perfectly encapsulates what we mean by pagability. for something
to be pageable, it does not have to have an item range or a first page.
here's what i suggest: drop EVERYTHING you've been thinking about
and start fresh with a new package that doesn't depend on /anything else/
called wicket.markup.html.navigation.paging and implement the interface
above starting with the classes and class names i suggested earlier.
do this
as simply as possible. when you've got the basic idea of paging
abstracted,
encapsulated and implemented as perfectly as possible, i can try to code
review if you like. my very strong educated guess is that if it's done
right,
we will find that this component is reusable all over the place,
including
within listview. if that doesn't turn out to be the case, the problem
will likely
not be with the new paging package, which will be a very nicely reusable
component package. sound good?
as far as the links go, i believe the PagingNavigation component should
be able to use a self-link that sets the current page through the
interface
above. then when the page refreshes, the pageable thing will draw with
its new current page. if the thing that's pageable has special
requirements
like maybe it's bookmarkable, then the implementation of
IPageable.setCurrentPage()
would have to handle that situation by redirecting to the appropriate
bookmarkable
page with the right parameters.
i will admit that i'm guessing a little here and it's starting to feel
like it would
be quicker to just do this if i have to continue to explain... but i
think the above
should be enough.... please have a go at it if it is. i think it's
right and that it
will work out really nicely.
Igor Vaynberg wrote:
So we have
interface ipageable {
irange getPageRange();
irange getItemRange();
void setPage(int page) ????
void setFirstPage(int page) ????
void setPageRange(int first, int last) ????
}
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
