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]
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?
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?
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?
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?
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 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
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 - To unsubscribe, e-mail: users- [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
