ok. Then i do think we still need a PageableListView because if we let
ListView be pageable
then it is more or less PageableListView will become ListView.
But i like the idea. For example a Form could implement IPageable and
has a row per page of one
and then the navigator just let me scroll through all records. that is
beneath the form.
Jup very nice.
johan
Jonathan Locke wrote:
listview. that's the thing that is paged. what is a page is up to the
thing being paged,
not the thing doing the paging navigation.
the concept of "page" doesn't necessarily even have rows. you could
be paging
something else entirely... like product details panels or whatever...
this is why i suggest
trying to stop thinking about listview... build the simple modular
thing first. then
expand as needed.
Johan Compagner wrote:
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
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
