Re: [Wicket-user] IPageable interface
you did. it's not in IPageable. that's an /extra/ function of /some/ components that happen to implement IPageable. an important distinction. i really did state this carefully if you were reading it: "i dunno. seems to me that the paging component should just change pages. we ought to have a separate component to deal with item count feedback like this. if you look at google's site, the paging component and the "showing x to y of z" feedback are at opposite ends of the page. i don't think they're related really. */i think this should probably be a separate interface like IRange or ISelection or something /*that you could hook up to something that shows the range of something being displayed. you wouldn't necessarily have to have paging when you showed the range or vice versa." Igor Vaynberg wrote: That was Jonathan's idea. That's why Irange getPageRange() is in the ipageable. It returns the first, and the last page being displayed, as well as the total num of pages available. Unless I misunderstood something... -Igor -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johan Compagner Sent: Wednesday, August 03, 2005 2:18 PM To: wicket-user@lists.sourceforge.net Subject: Re: [Wicket-user] IPageable interface Why would a component display 3 pages at a time? Pageable means that it pages (read displays) 1 page at one time. if you want to display 3 pages at the time just make youre page bigger (if one page displays 10 rows then make it 30) johan Igor Vaynberg wrote: Maybe I didn't express what I wanted clearly. I think setCurrentPage(int) is fine if the component is displaying a page at a time, but what does setCurrentPage(int) mean if the component is displaying 3 pages at a time? Is it setting the first page of 3? Or is it setting the last page of 3? Or the middle page? And what I meant was just having one of those methods in ipageable not all 3, my question was which one do you guys think is more appropriate... -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
Re: [Wicket-user] IPageable interface
anywhere you need to do paging. whether in a page footer or a list view navigation component or somewhere else. it's a general component whereas the listview nav that knows about items and such is really not quite general since it's tied to a certain idea of what does on the pages that are being paged. make sense? Dariusz Wojtas wrote: Hmmm, little late, but - now I understood your intention. Interface, simple, powerful, but limited only to the navigation component. Then your 3 method interface is enough. Where exactly is it going to be used? Only to describe some page footer, or something more? Dariusz Wojtas On 8/3/05, Jonathan Locke <[EMAIL PROTECTED]> wrote: 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 --- 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
RE: [Wicket-user] IPageable interface
That was Jonathan's idea. That's why Irange getPageRange() is in the ipageable. It returns the first, and the last page being displayed, as well as the total num of pages available. Unless I misunderstood something... -Igor > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Johan Compagner > Sent: Wednesday, August 03, 2005 2:18 PM > To: wicket-user@lists.sourceforge.net > Subject: Re: [Wicket-user] IPageable interface > > Why would a component display 3 pages at a time? > Pageable means that it pages (read displays) 1 page at one time. > if you want to display 3 pages at the time just make youre > page bigger (if one page displays 10 rows then make it 30) > > johan > > > Igor Vaynberg wrote: > > Maybe I didn't express what I wanted clearly. > > > > I think setCurrentPage(int) is fine if the component is > displaying a > > page at a time, but what does setCurrentPage(int) mean if the > > component is displaying 3 pages at a time? Is it setting the first > > page of 3? Or is it setting the last page of 3? Or the middle page? > > > > And what I meant was just having one of those methods in > ipageable not > > all 3, my question was which one do you guys think is more > appropriate... > > > > -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
Re: [Wicket-user] IPageable interface
Why would a component display 3 pages at a time? Pageable means that it pages (read displays) 1 page at one time. if you want to display 3 pages at the time just make youre page bigger (if one page displays 10 rows then make it 30) johan Igor Vaynberg wrote: Maybe I didn’t express what I wanted clearly. I think setCurrentPage(int) is fine if the component is displaying a page at a time, but what does setCurrentPage(int) mean if the component is displaying 3 pages at a time? Is it setting the first page of 3? Or is it setting the last page of 3? Or the middle page? And what I meant was just having one of those methods in ipageable not all 3, my question was which one do you guys think is more appropriate... -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
Re: [Wicket-user] IPageable interface
yes i get that. But somewhere in the post it is mentioned that we could deprecate PageableListView This is not the case with such an interface we are describing now Because ListView by itself shouldn't implement IPageable then because it shouldn't have any knowledge of that. All current listview implementations used are not used for paging and never will be. If we did made ListView implements the new IPageable interface then listview just becomes PageableListView I think we should developers choose what they want. johan Phil Kulak wrote: Because defining how many rows there are are useless if you don't attach a paging component... I disagree. So you're stuck on page one with no way to get to other pages until you add a pager. What's the problem with that? I don't think it's so disasterous that we need to clutter the IPageable interface. Let the pageable component worry about how it renders itself and and the pager worry about paging. --- 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
Re: [Wicket-user] IPageable interface
Hmmm, little late, but - now I understood your intention. Interface, simple, powerful, but limited only to the navigation component. Then your 3 method interface is enough. Where exactly is it going to be used? Only to describe some page footer, or something more? Dariusz Wojtas On 8/3/05, Jonathan Locke <[EMAIL PROTECTED]> wrote: > > 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 --- 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
Re: [Wicket-user] IPageable interface
totally, dude. right on. Phil Kulak wrote: Because defining how many rows there are are useless if you don't attach a paging component... I disagree. So you're stuck on page one with no way to get to other pages until you add a pager. What's the problem with that? I don't think it's so disasterous that we need to clutter the IPageable interface. Let the pageable component worry about how it renders itself and and the pager worry about paging. --- 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
Re: [Wicket-user] IPageable interface
> Because defining how many rows there are are useless if you don't attach > a paging component... I disagree. So you're stuck on page one with no way to get to other pages until you add a pager. What's the problem with that? I don't think it's so disasterous that we need to clutter the IPageable interface. Let the pageable component worry about how it renders itself and and the pager worry about paging. --- 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
Re: [Wicket-user] IPageable interface
yup yup
Johan Compagner wrote:
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 & Measu
Re: [Wicket-user] IPageable interface
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
Re: [Wicket-user] IPageable interface
YES!!! that's it. the navigator just changes the current page. it
shouldn't even know
there's a list at all.
Johan Compagner wrote:
What do you need an iterator()?
The Navigator component doesn't want the items of the list. It only
wants to set
which page the list should render now and then represent that in its
navigator links << 1 2 3 4 >>>
johan
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
---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Drive
Re: [Wicket-user] IPageable interface
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
Re: [Wicket-user] IPageable interface
What do you need an iterator()?
The Navigator component doesn't want the items of the list. It only
wants to set
which page the list should render now and then represent that in its
navigator links << 1 2 3 4 >>>
johan
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
Re: [Wicket-user] IPageable interface
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
Re: [Wicket-user] IPageable interface
hmm of course then a ListView has also the setRowCount() method
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
Re: [Wicket-user] IPageable interface
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
Re: [Wicket-user] IPageable interface
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
