Re: T5: Implementing a Grid index strategy?
Sounds OK, but in details I would prefer just to define the rows for the "current" page and the label(s). Otherwise we are still slipping into the idea of a fixed nr of pages which makes it complicated for some reasonable strategies like my index. I've actually implemented code with such a sliding window without any major problems, but a lot of duplication :-( I. e., the Grid really just needs to know what to display from the datasource. The rest: nr of pages, what to display when and so forth would be the GridPagerModel's responsibility. Navigation links would use the GridPagerModel. But this is a little more, and reasonably postponed for a while (3.1?). For now, I think will just patch current Grid, creating a new component doing what I need. It's not nice, but probably the fastest way. Robert Zeigler wrote: I had the same thought a few days ago; there's a GridDataModel, and a GridSortModel; why not have a GridPagerModel? The default implementation would have the same behavior as now: take the number of rows and the rows per page, and build fixed-length pages. That's good for a large number of cases. But users could provide their own GridPagerModel which the grid (or grid pager) would query for: The # of pages The page labels The rows for a particular page However, this seems like the sort of thing that should come in 5.1, imo. Robert On Mar 11, 2008, at 3/119:24 AM , Alec Leamas wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Implementing a Grid index strategy?
I had the same thought a few days ago; there's a GridDataModel, and a GridSortModel; why not have a GridPagerModel? The default implementation would have the same behavior as now: take the number of rows and the rows per page, and build fixed-length pages. That's good for a large number of cases. But users could provide their own GridPagerModel which the grid (or grid pager) would query for: The # of pages The page labels The rows for a particular page However, this seems like the sort of thing that should come in 5.1, imo. Robert On Mar 11, 2008, at 3/119:24 AM , Alec Leamas wrote: Just to make it clear: I don't really want anything "more" than current functionality from the Grid, just a better point to override it. Changing the internal idea of "current page/current row" would give exactly the same functionality as today, but with better options to modify it using another GridPager. Now I need some time to understand this idea to filter the data to the Grid :-) Cheers --Alec Howard Lewis Ship wrote: The built-in components can not be all things to all people. You can often reuse some of the sub-components of Grid to build a customized Grid. I think I would use a filter on the Grid; so you have a set of controls for selecting the search letter, that applies a filter to the Grid contents, then the Grid renders just the values within that letter. On Tue, Mar 11, 2008 at 6:58 AM, Alec Leamas <[EMAIL PROTECTED]> wrote: True. And a little better. But it still like pushing a square into a round hole: Tapestry does not support the "natural" way to do it. I presume we agree that from a user point of view, start presenting the entries we are looking for is the "expected" thing. Also, there is actually more in this. I can think of other, reasonable paging strategies e. g., some entries of overlap for each page. My gut feeling is that Grid should be more generic, and that a GridPager should be free to define whatever strategy it wants. I think the only thing which needs to be changed is the Grid's idea of the "actual page" being a row nr instead of a page nr. It shouldn't be hard to make this change without affecting current code. If required, one could even let setPage remain with current semantics?! Davor Hrg wrote: > hm, > you can relatively easily mark the first one, > so it is noticed instantly > and that way pager and indexer are not in conflict.. > > definitely an user friendly feature you're creating there :) > > Davor Hrg > > On Tue, Mar 11, 2008 at 2:43 PM, Alec Leamas <[EMAIL PROTECTED] > wrote: > >> It's an option, but not a good one. Looking for 'l' might present 24 >> users beginning with 'k', and a last line of 'Larsson'. This is just not >> intuitive. >> >> The expected behaveour of an index link is to start presenting entries >> according to the link. (like javadoc :-) ) >> >> --alec >> >> >> >> Davor Hrg wrote: >> > why is calculating page not an option ? >> > >> > does selected row have to be first or you just >> > wan to navigate to the fist page that contains the row ? >> > >> > Davor Hrg >> > >> > >> > On Tue, Mar 11, 2008 at 2:15 PM, Alec Leamas <[EMAIL PROTECTED] > wrote: >> > >> >> I'm about to convert some T4 code to T5. In this code, I have a large , >> >> paged table of persons with index links with the letters 'a' ..'z' at >> >> the bottom of each page . Clicking the 'c' link starts presenting the >> >> first persons with a name beginning with 'c', There are also links to go >> >> on page forward/backward. Like this: >> >> >> >> < a b c d e f g h i j k l m n o p q r s t u v x y z > >> >> >> >> This is actually useful, it's much easier to press 'l' looking for >> >> leamas the to try to guess which page nr he is at. >> >> >> >> In T4, I had to recode large part of the table stuff , including sort >> >> etc, to implement this. I hoped T5 would be better, but the problem seem >> >> to be still here: The Grid has an internal model of a fixed number of >> >> pages, and a current page nr. This doesn't work with the sliding page >> >> window required to present "the first page of users beginning with x'. >> >> For this to work, the actual page must be defined by the first row nr. >> >> >> >> In other words: A flexible Grid should be able to position to any row >> >> in the data, not just to even page boundaries (according to the >> >> default's definition of a page). >> >> >> >> So, two questions: >> >> - Am I right thinking that implementing a GridIndex analog to GridPager >> >> isn't straightforward in current design? >> >> - Would i be possible to change the code in Grid to open up for other >> >> paging strategies than a fixed nr of (numbered) pages? In particular, >> >> would it be possible to store currentRow instead of currentPage in Grid? >> >> >> >> >> >> Cheers, >> >> >> >> --alec >> >>
Re: T5: Implementing a Grid index strategy?
Just to make it clear: I don't really want anything "more" than current functionality from the Grid, just a better point to override it. Changing the internal idea of "current page/current row" would give exactly the same functionality as today, but with better options to modify it using another GridPager. Now I need some time to understand this idea to filter the data to the Grid :-) Cheers --Alec Howard Lewis Ship wrote: The built-in components can not be all things to all people. You can often reuse some of the sub-components of Grid to build a customized Grid. I think I would use a filter on the Grid; so you have a set of controls for selecting the search letter, that applies a filter to the Grid contents, then the Grid renders just the values within that letter. On Tue, Mar 11, 2008 at 6:58 AM, Alec Leamas <[EMAIL PROTECTED]> wrote: True. And a little better. But it still like pushing a square into a round hole: Tapestry does not support the "natural" way to do it. I presume we agree that from a user point of view, start presenting the entries we are looking for is the "expected" thing. Also, there is actually more in this. I can think of other, reasonable paging strategies e. g., some entries of overlap for each page. My gut feeling is that Grid should be more generic, and that a GridPager should be free to define whatever strategy it wants. I think the only thing which needs to be changed is the Grid's idea of the "actual page" being a row nr instead of a page nr. It shouldn't be hard to make this change without affecting current code. If required, one could even let setPage remain with current semantics?! Davor Hrg wrote: > hm, > you can relatively easily mark the first one, > so it is noticed instantly > and that way pager and indexer are not in conflict.. > > definitely an user friendly feature you're creating there :) > > Davor Hrg > > On Tue, Mar 11, 2008 at 2:43 PM, Alec Leamas <[EMAIL PROTECTED]> wrote: > >> It's an option, but not a good one. Looking for 'l' might present 24 >> users beginning with 'k', and a last line of 'Larsson'. This is just not >> intuitive. >> >> The expected behaveour of an index link is to start presenting entries >> according to the link. (like javadoc :-) ) >> >> --alec >> >> >> >> Davor Hrg wrote: >> > why is calculating page not an option ? >> > >> > does selected row have to be first or you just >> > wan to navigate to the fist page that contains the row ? >> > >> > Davor Hrg >> > >> > >> > On Tue, Mar 11, 2008 at 2:15 PM, Alec Leamas <[EMAIL PROTECTED]> wrote: >> > >> >> I'm about to convert some T4 code to T5. In this code, I have a large , >> >> paged table of persons with index links with the letters 'a' ..'z' at >> >> the bottom of each page . Clicking the 'c' link starts presenting the >> >> first persons with a name beginning with 'c', There are also links to go >> >> on page forward/backward. Like this: >> >> >> >> < a b c d e f g h i j k l m n o p q r s t u v x y z > >> >> >> >> This is actually useful, it's much easier to press 'l' looking for >> >> leamas the to try to guess which page nr he is at. >> >> >> >> In T4, I had to recode large part of the table stuff , including sort >> >> etc, to implement this. I hoped T5 would be better, but the problem seem >> >> to be still here: The Grid has an internal model of a fixed number of >> >> pages, and a current page nr. This doesn't work with the sliding page >> >> window required to present "the first page of users beginning with x'. >> >> For this to work, the actual page must be defined by the first row nr. >> >> >> >> In other words: A flexible Grid should be able to position to any row >> >> in the data, not just to even page boundaries (according to the >> >> default's definition of a page). >> >> >> >> So, two questions: >> >> - Am I right thinking that implementing a GridIndex analog to GridPager >> >> isn't straightforward in current design? >> >> - Would i be possible to change the code in Grid to open up for other >> >> paging strategies than a fixed nr of (numbered) pages? In particular, >> >> would it be possible to store currentRow instead of currentPage in Grid? >> >> >> >> >> >> Cheers, >> >> >> >> --alec >> >> >> >> - >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> >> >> > >> > - >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Implementing a Grid index strategy?
The built-in components can not be all things to all people. You can often reuse some of the sub-components of Grid to build a customized Grid. I think I would use a filter on the Grid; so you have a set of controls for selecting the search letter, that applies a filter to the Grid contents, then the Grid renders just the values within that letter. On Tue, Mar 11, 2008 at 6:58 AM, Alec Leamas <[EMAIL PROTECTED]> wrote: > True. And a little better. But it still like pushing a square into a > round hole: Tapestry does not support the "natural" way to do it. I > presume we agree that from a user point of view, start presenting the > entries we are looking for is the "expected" thing. > > Also, there is actually more in this. I can think of other, reasonable > paging strategies e. g., some entries of overlap for each page. My gut > feeling is that Grid should be more generic, and that a GridPager should > be free to define whatever strategy it wants. I think the only thing > which needs to be changed is the Grid's idea of the "actual page" being > a row nr instead of a page nr. It shouldn't be hard to make this change > without affecting current code. If required, one could even let setPage > remain with current semantics?! > > > > > Davor Hrg wrote: > > hm, > > you can relatively easily mark the first one, > > so it is noticed instantly > > and that way pager and indexer are not in conflict.. > > > > definitely an user friendly feature you're creating there :) > > > > Davor Hrg > > > > On Tue, Mar 11, 2008 at 2:43 PM, Alec Leamas <[EMAIL PROTECTED]> wrote: > > > >> It's an option, but not a good one. Looking for 'l' might present 24 > >> users beginning with 'k', and a last line of 'Larsson'. This is just not > >> intuitive. > >> > >> The expected behaveour of an index link is to start presenting entries > >> according to the link. (like javadoc :-) ) > >> > >> --alec > >> > >> > >> > >> Davor Hrg wrote: > >> > why is calculating page not an option ? > >> > > >> > does selected row have to be first or you just > >> > wan to navigate to the fist page that contains the row ? > >> > > >> > Davor Hrg > >> > > >> > > >> > On Tue, Mar 11, 2008 at 2:15 PM, Alec Leamas <[EMAIL PROTECTED]> wrote: > >> > > >> >> I'm about to convert some T4 code to T5. In this code, I have a large > , > >> >> paged table of persons with index links with the letters 'a' ..'z' at > >> >> the bottom of each page . Clicking the 'c' link starts presenting > the > >> >> first persons with a name beginning with 'c', There are also links > to go > >> >> on page forward/backward. Like this: > >> >> > >> >> < a b c d e f g h i j k l m n o p q r s t u v x y z > > >> >> > >> >> This is actually useful, it's much easier to press 'l' looking for > >> >> leamas the to try to guess which page nr he is at. > >> >> > >> >> In T4, I had to recode large part of the table stuff , including sort > >> >> etc, to implement this. I hoped T5 would be better, but the problem > seem > >> >> to be still here: The Grid has an internal model of a fixed number of > >> >> pages, and a current page nr. This doesn't work with the sliding page > >> >> window required to present "the first page of users beginning with > x'. > >> >> For this to work, the actual page must be defined by the first row > nr. > >> >> > >> >> In other words: A flexible Grid should be able to position to any > row > >> >> in the data, not just to even page boundaries (according to the > >> >> default's definition of a page). > >> >> > >> >> So, two questions: > >> >> - Am I right thinking that implementing a GridIndex analog to > GridPager > >> >> isn't straightforward in current design? > >> >> - Would i be possible to change the code in Grid to open up for other > >> >> paging strategies than a fixed nr of (numbered) pages? In particular, > >> >> would it be possible to store currentRow instead of currentPage in > Grid? > >> >> > >> >> > >> >> Cheers, > >> >> > >> >> --alec > >> >> > >> >> - > >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >> For additional commands, e-mail: [EMAIL PROTECTED] > >> >> > >> >> > >> >> > >> > > >> > - > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -
Re: T5: Implementing a Grid index strategy?
sounds reasonable, you feel strong about this, so add a jira to make it a serious req. Davor Hrg On Tue, Mar 11, 2008 at 2:58 PM, Alec Leamas <[EMAIL PROTECTED]> wrote: > True. And a little better. But it still like pushing a square into a > round hole: Tapestry does not support the "natural" way to do it. I > presume we agree that from a user point of view, start presenting the > entries we are looking for is the "expected" thing. > > Also, there is actually more in this. I can think of other, reasonable > paging strategies e. g., some entries of overlap for each page. My gut > feeling is that Grid should be more generic, and that a GridPager should > be free to define whatever strategy it wants. I think the only thing > which needs to be changed is the Grid's idea of the "actual page" being > a row nr instead of a page nr. It shouldn't be hard to make this change > without affecting current code. If required, one could even let setPage > remain with current semantics?! > > > > > Davor Hrg wrote: > > hm, > > you can relatively easily mark the first one, > > so it is noticed instantly > > and that way pager and indexer are not in conflict.. > > > > definitely an user friendly feature you're creating there :) > > > > Davor Hrg > > > > On Tue, Mar 11, 2008 at 2:43 PM, Alec Leamas <[EMAIL PROTECTED]> wrote: > > > >> It's an option, but not a good one. Looking for 'l' might present 24 > >> users beginning with 'k', and a last line of 'Larsson'. This is just not > >> intuitive. > >> > >> The expected behaveour of an index link is to start presenting entries > >> according to the link. (like javadoc :-) ) > >> > >> --alec > >> > >> > >> > >> Davor Hrg wrote: > >> > why is calculating page not an option ? > >> > > >> > does selected row have to be first or you just > >> > wan to navigate to the fist page that contains the row ? > >> > > >> > Davor Hrg > >> > > >> > > >> > On Tue, Mar 11, 2008 at 2:15 PM, Alec Leamas <[EMAIL PROTECTED]> wrote: > >> > > >> >> I'm about to convert some T4 code to T5. In this code, I have a large > , > >> >> paged table of persons with index links with the letters 'a' ..'z' at > >> >> the bottom of each page . Clicking the 'c' link starts presenting > the > >> >> first persons with a name beginning with 'c', There are also links > to go > >> >> on page forward/backward. Like this: > >> >> > >> >> < a b c d e f g h i j k l m n o p q r s t u v x y z > > >> >> > >> >> This is actually useful, it's much easier to press 'l' looking for > >> >> leamas the to try to guess which page nr he is at. > >> >> > >> >> In T4, I had to recode large part of the table stuff , including sort > >> >> etc, to implement this. I hoped T5 would be better, but the problem > seem > >> >> to be still here: The Grid has an internal model of a fixed number of > >> >> pages, and a current page nr. This doesn't work with the sliding page > >> >> window required to present "the first page of users beginning with > x'. > >> >> For this to work, the actual page must be defined by the first row > nr. > >> >> > >> >> In other words: A flexible Grid should be able to position to any > row > >> >> in the data, not just to even page boundaries (according to the > >> >> default's definition of a page). > >> >> > >> >> So, two questions: > >> >> - Am I right thinking that implementing a GridIndex analog to > GridPager > >> >> isn't straightforward in current design? > >> >> - Would i be possible to change the code in Grid to open up for other > >> >> paging strategies than a fixed nr of (numbered) pages? In particular, > >> >> would it be possible to store currentRow instead of currentPage in > Grid? > >> >> > >> >> > >> >> Cheers, > >> >> > >> >> --alec > >> >> > >> >> - > >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >> For additional commands, e-mail: [EMAIL PROTECTED] > >> >> > >> >> > >> >> > >> > > >> > - > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscrib
Re: T5: Implementing a Grid index strategy?
True. And a little better. But it still like pushing a square into a round hole: Tapestry does not support the "natural" way to do it. I presume we agree that from a user point of view, start presenting the entries we are looking for is the "expected" thing. Also, there is actually more in this. I can think of other, reasonable paging strategies e. g., some entries of overlap for each page. My gut feeling is that Grid should be more generic, and that a GridPager should be free to define whatever strategy it wants. I think the only thing which needs to be changed is the Grid's idea of the "actual page" being a row nr instead of a page nr. It shouldn't be hard to make this change without affecting current code. If required, one could even let setPage remain with current semantics?! Davor Hrg wrote: hm, you can relatively easily mark the first one, so it is noticed instantly and that way pager and indexer are not in conflict.. definitely an user friendly feature you're creating there :) Davor Hrg On Tue, Mar 11, 2008 at 2:43 PM, Alec Leamas <[EMAIL PROTECTED]> wrote: It's an option, but not a good one. Looking for 'l' might present 24 users beginning with 'k', and a last line of 'Larsson'. This is just not intuitive. The expected behaveour of an index link is to start presenting entries according to the link. (like javadoc :-) ) --alec Davor Hrg wrote: > why is calculating page not an option ? > > does selected row have to be first or you just > wan to navigate to the fist page that contains the row ? > > Davor Hrg > > > On Tue, Mar 11, 2008 at 2:15 PM, Alec Leamas <[EMAIL PROTECTED]> wrote: > >> I'm about to convert some T4 code to T5. In this code, I have a large , >> paged table of persons with index links with the letters 'a' ..'z' at >> the bottom of each page . Clicking the 'c' link starts presenting the >> first persons with a name beginning with 'c', There are also links to go >> on page forward/backward. Like this: >> >> < a b c d e f g h i j k l m n o p q r s t u v x y z > >> >> This is actually useful, it's much easier to press 'l' looking for >> leamas the to try to guess which page nr he is at. >> >> In T4, I had to recode large part of the table stuff , including sort >> etc, to implement this. I hoped T5 would be better, but the problem seem >> to be still here: The Grid has an internal model of a fixed number of >> pages, and a current page nr. This doesn't work with the sliding page >> window required to present "the first page of users beginning with x'. >> For this to work, the actual page must be defined by the first row nr. >> >> In other words: A flexible Grid should be able to position to any row >> in the data, not just to even page boundaries (according to the >> default's definition of a page). >> >> So, two questions: >> - Am I right thinking that implementing a GridIndex analog to GridPager >> isn't straightforward in current design? >> - Would i be possible to change the code in Grid to open up for other >> paging strategies than a fixed nr of (numbered) pages? In particular, >> would it be possible to store currentRow instead of currentPage in Grid? >> >> >> Cheers, >> >> --alec >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Implementing a Grid index strategy?
or even highliht all that begin with selected letter so user is aware where the list ends Davor Hrg On Tue, Mar 11, 2008 at 2:48 PM, Davor Hrg <[EMAIL PROTECTED]> wrote: > hm, > you can relatively easily mark the first one, > so it is noticed instantly > and that way pager and indexer are not in conflict.. > > definitely an user friendly feature you're creating there :) > > Davor Hrg > > > > On Tue, Mar 11, 2008 at 2:43 PM, Alec Leamas <[EMAIL PROTECTED]> wrote: > > It's an option, but not a good one. Looking for 'l' might present 24 > > users beginning with 'k', and a last line of 'Larsson'. This is just not > > intuitive. > > > > The expected behaveour of an index link is to start presenting entries > > according to the link. (like javadoc :-) ) > > > > --alec > > > > > > > > Davor Hrg wrote: > > > why is calculating page not an option ? > > > > > > does selected row have to be first or you just > > > wan to navigate to the fist page that contains the row ? > > > > > > Davor Hrg > > > > > > > > > On Tue, Mar 11, 2008 at 2:15 PM, Alec Leamas <[EMAIL PROTECTED]> wrote: > > > > > >> I'm about to convert some T4 code to T5. In this code, I have a large , > > >> paged table of persons with index links with the letters 'a' ..'z' at > > >> the bottom of each page . Clicking the 'c' link starts presenting > the > > >> first persons with a name beginning with 'c', There are also links to > go > > >> on page forward/backward. Like this: > > >> > > >> < a b c d e f g h i j k l m n o p q r s t u v x y z > > > >> > > >> This is actually useful, it's much easier to press 'l' looking for > > >> leamas the to try to guess which page nr he is at. > > >> > > >> In T4, I had to recode large part of the table stuff , including sort > > >> etc, to implement this. I hoped T5 would be better, but the problem > seem > > >> to be still here: The Grid has an internal model of a fixed number of > > >> pages, and a current page nr. This doesn't work with the sliding page > > >> window required to present "the first page of users beginning with x'. > > >> For this to work, the actual page must be defined by the first row nr. > > >> > > >> In other words: A flexible Grid should be able to position to any row > > >> in the data, not just to even page boundaries (according to the > > >> default's definition of a page). > > >> > > >> So, two questions: > > >> - Am I right thinking that implementing a GridIndex analog to > GridPager > > >> isn't straightforward in current design? > > >> - Would i be possible to change the code in Grid to open up for other > > >> paging strategies than a fixed nr of (numbered) pages? In particular, > > >> would it be possible to store currentRow instead of currentPage in > Grid? > > >> > > >> > > >> Cheers, > > >> > > >> --alec > > >> > > >> - > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > >> > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Implementing a Grid index strategy?
hm, you can relatively easily mark the first one, so it is noticed instantly and that way pager and indexer are not in conflict.. definitely an user friendly feature you're creating there :) Davor Hrg On Tue, Mar 11, 2008 at 2:43 PM, Alec Leamas <[EMAIL PROTECTED]> wrote: > It's an option, but not a good one. Looking for 'l' might present 24 > users beginning with 'k', and a last line of 'Larsson'. This is just not > intuitive. > > The expected behaveour of an index link is to start presenting entries > according to the link. (like javadoc :-) ) > > --alec > > > > Davor Hrg wrote: > > why is calculating page not an option ? > > > > does selected row have to be first or you just > > wan to navigate to the fist page that contains the row ? > > > > Davor Hrg > > > > > > On Tue, Mar 11, 2008 at 2:15 PM, Alec Leamas <[EMAIL PROTECTED]> wrote: > > > >> I'm about to convert some T4 code to T5. In this code, I have a large , > >> paged table of persons with index links with the letters 'a' ..'z' at > >> the bottom of each page . Clicking the 'c' link starts presenting the > >> first persons with a name beginning with 'c', There are also links to go > >> on page forward/backward. Like this: > >> > >> < a b c d e f g h i j k l m n o p q r s t u v x y z > > >> > >> This is actually useful, it's much easier to press 'l' looking for > >> leamas the to try to guess which page nr he is at. > >> > >> In T4, I had to recode large part of the table stuff , including sort > >> etc, to implement this. I hoped T5 would be better, but the problem seem > >> to be still here: The Grid has an internal model of a fixed number of > >> pages, and a current page nr. This doesn't work with the sliding page > >> window required to present "the first page of users beginning with x'. > >> For this to work, the actual page must be defined by the first row nr. > >> > >> In other words: A flexible Grid should be able to position to any row > >> in the data, not just to even page boundaries (according to the > >> default's definition of a page). > >> > >> So, two questions: > >> - Am I right thinking that implementing a GridIndex analog to GridPager > >> isn't straightforward in current design? > >> - Would i be possible to change the code in Grid to open up for other > >> paging strategies than a fixed nr of (numbered) pages? In particular, > >> would it be possible to store currentRow instead of currentPage in > Grid? > >> > >> > >> Cheers, > >> > >> --alec > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Implementing a Grid index strategy?
It's an option, but not a good one. Looking for 'l' might present 24 users beginning with 'k', and a last line of 'Larsson'. This is just not intuitive. The expected behaveour of an index link is to start presenting entries according to the link. (like javadoc :-) ) --alec Davor Hrg wrote: why is calculating page not an option ? does selected row have to be first or you just wan to navigate to the fist page that contains the row ? Davor Hrg On Tue, Mar 11, 2008 at 2:15 PM, Alec Leamas <[EMAIL PROTECTED]> wrote: I'm about to convert some T4 code to T5. In this code, I have a large , paged table of persons with index links with the letters 'a' ..'z' at the bottom of each page . Clicking the 'c' link starts presenting the first persons with a name beginning with 'c', There are also links to go on page forward/backward. Like this: < a b c d e f g h i j k l m n o p q r s t u v x y z > This is actually useful, it's much easier to press 'l' looking for leamas the to try to guess which page nr he is at. In T4, I had to recode large part of the table stuff , including sort etc, to implement this. I hoped T5 would be better, but the problem seem to be still here: The Grid has an internal model of a fixed number of pages, and a current page nr. This doesn't work with the sliding page window required to present "the first page of users beginning with x'. For this to work, the actual page must be defined by the first row nr. In other words: A flexible Grid should be able to position to any row in the data, not just to even page boundaries (according to the default's definition of a page). So, two questions: - Am I right thinking that implementing a GridIndex analog to GridPager isn't straightforward in current design? - Would i be possible to change the code in Grid to open up for other paging strategies than a fixed nr of (numbered) pages? In particular, would it be possible to store currentRow instead of currentPage in Grid? Cheers, --alec - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Implementing a Grid index strategy?
why is calculating page not an option ? does selected row have to be first or you just wan to navigate to the fist page that contains the row ? Davor Hrg On Tue, Mar 11, 2008 at 2:15 PM, Alec Leamas <[EMAIL PROTECTED]> wrote: > I'm about to convert some T4 code to T5. In this code, I have a large , > paged table of persons with index links with the letters 'a' ..'z' at > the bottom of each page . Clicking the 'c' link starts presenting the > first persons with a name beginning with 'c', There are also links to go > on page forward/backward. Like this: > > < a b c d e f g h i j k l m n o p q r s t u v x y z > > > This is actually useful, it's much easier to press 'l' looking for > leamas the to try to guess which page nr he is at. > > In T4, I had to recode large part of the table stuff , including sort > etc, to implement this. I hoped T5 would be better, but the problem seem > to be still here: The Grid has an internal model of a fixed number of > pages, and a current page nr. This doesn't work with the sliding page > window required to present "the first page of users beginning with x'. > For this to work, the actual page must be defined by the first row nr. > > In other words: A flexible Grid should be able to position to any row > in the data, not just to even page boundaries (according to the > default's definition of a page). > > So, two questions: > - Am I right thinking that implementing a GridIndex analog to GridPager > isn't straightforward in current design? > - Would i be possible to change the code in Grid to open up for other > paging strategies than a fixed nr of (numbered) pages? In particular, > would it be possible to store currentRow instead of currentPage in Grid? > > > Cheers, > > --alec > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
T5: Implementing a Grid index strategy?
I'm about to convert some T4 code to T5. In this code, I have a large , paged table of persons with index links with the letters 'a' ..'z' at the bottom of each page . Clicking the 'c' link starts presenting the first persons with a name beginning with 'c', There are also links to go on page forward/backward. Like this: < a b c d e f g h i j k l m n o p q r s t u v x y z > This is actually useful, it's much easier to press 'l' looking for leamas the to try to guess which page nr he is at. In T4, I had to recode large part of the table stuff , including sort etc, to implement this. I hoped T5 would be better, but the problem seem to be still here: The Grid has an internal model of a fixed number of pages, and a current page nr. This doesn't work with the sliding page window required to present "the first page of users beginning with x'. For this to work, the actual page must be defined by the first row nr. In other words: A flexible Grid should be able to position to any row in the data, not just to even page boundaries (according to the default's definition of a page). So, two questions: - Am I right thinking that implementing a GridIndex analog to GridPager isn't straightforward in current design? - Would i be possible to change the code in Grid to open up for other paging strategies than a fixed nr of (numbered) pages? In particular, would it be possible to store currentRow instead of currentPage in Grid? Cheers, --alec - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
