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 slid
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 case
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 anothe
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
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" w
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 thi
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
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 n
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 lar
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
11 matches
Mail list logo
