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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
