this is where we differ. my first guess is that a page has no "size". it's an abstract thing.

Dariusz Wojtas wrote:

If I understand correctly, IPageable describes something that:
 * represents some range of data
 * data is divided into pages
 * every page has some size (although it doesn't oblige that all
pages are of the same size)
 * some component, or some user logic, may need to have access to the data

The 3 methods IPageable interface below is simple, nice, but I think it lacks 2 important methods
 public int getPageSize();
 public Iterator iterator();

Exposing these methods is trivial on whatever the component is based:
a collection, Map or an array - but makes this interface really
powerful.

Dariusz Wojtas


On 8/3/05, Jonathan Locke <[EMAIL PROTECTED]> 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) ????
}

What strategy/name do we want to use for setting the page range on a
pageable component? If we allow setPageRange(int first, int last) it might
be more difficult to implement simpler components which only display a page
at a time.

Btw, figured out why getPage() was needed. The navigation links don't have
access to their own page when they are being constructed so they pulled it
off the passed in pageable component.

-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

Reply via email to