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 PROTECTED]

Reply via email to