Re: Newbie,T5: Grid limitations (long).
There's certainly an issue that if the Grid component grew to encompass every possible user's most remote needs, the end result would not be useable by anybody (a Grid component with 27 required parameters of which six are detailed interfaces, etc., etc.). The point is, the common components need to hit a 90/10 rule of usefulness. A secondary goal would be to make the underlying components of Grid (GridRows, GridColumns, GridPager) easy to reuse/extend for a more application-specific Grid implementation. On Tue, Mar 25, 2008 at 2:41 PM, Alec Leamas <[EMAIL PROTECTED]> wrote: > Jesper Zedlitz wrote: > > Alec Leamas wrote: > > > >> - The paging policy with a fixed number of numbered pages is hardcoded > >> and can't be changed. Other policies e. g., overlap between pages > >> > >> > > Isn't that something you can handle inside your own GridDataSource? With > the > > page number, the number of results per page, the number of overlapping > > items (ok, you need a separate parameter for that) it should be possible > > return the correct entries. > > > > > Obviouly, I was not clear about this. It's about starting a page at just > any item, not just on even page boundaries as defined by the page size. > See > > http://www.nabble.com/T5%2C-newbie%3A-Grid-use-w-dynamic-columns-td16080438.html > > >> - It is not possible to change the overall rendering of a row e. g,, to > >> to embed each ... in a > >> > >> > > That is not valid XHTML 1.0 Strict > > > > I do not know enough about the Grid component to write something about the > > other questions. What I miss is the "columns" attribute from T4's Table > > component.. > Yep, when coming from T4 you miss the column component. > > Anyway, I don't want to write bad HTML. So after some more RTFM I've > concluded that the microformat issue (the ... above) can be > resolved by the rowclass attribute, together with som explicit column > fomatting as described in the manual. > > One item of four resolved. Thanks! > > --alec > > > > - > 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]
Re: Newbie,T5: Grid limitations (long).
Jesper Zedlitz wrote: Alec Leamas wrote: - The paging policy with a fixed number of numbered pages is hardcoded and can't be changed. Other policies e. g., overlap between pages Isn't that something you can handle inside your own GridDataSource? With the page number, the number of results per page, the number of overlapping items (ok, you need a separate parameter for that) it should be possible return the correct entries. Obviouly, I was not clear about this. It's about starting a page at just any item, not just on even page boundaries as defined by the page size. See http://www.nabble.com/T5%2C-newbie%3A-Grid-use-w-dynamic-columns-td16080438.html - It is not possible to change the overall rendering of a row e. g,, to to embed each ... in a That is not valid XHTML 1.0 Strict I do not know enough about the Grid component to write something about the other questions. What I miss is the "columns" attribute from T4's Table component.. Yep, when coming from T4 you miss the column component. Anyway, I don't want to write bad HTML. So after some more RTFM I've concluded that the microformat issue (the ... above) can be resolved by the rowclass attribute, together with som explicit column fomatting as described in the manual. One item of four resolved. Thanks! --alec - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Newbie,T5: Grid limitations (long).
Alec Leamas wrote: > - The paging policy with a fixed number of numbered pages is hardcoded > and can't be changed. Other policies e. g., overlap between pages > Isn't that something you can handle inside your own GridDataSource? With the page number, the number of results per page, the number of overlapping items (ok, you need a separate parameter for that) it should be possible return the correct entries. > pages started at random points in the input vector is not possible. > Maybe this works: Inject the Grid component into your page using @Component private Grid grid; When setting up the result you set a random page - something like this: int numberOfPages = (int)(result.size()/grid.getRowsPerPage()); grid.setCurrentPage( (int)(Math.random() * numberOfPages) ); > - It is not possible to change the overall rendering of a row e. g,, to > to embed each ... in a > That is not valid XHTML 1.0 Strict I do not know enough about the Grid component to write something about the other questions. What I miss is the "columns" attribute from T4's Table component... Jesper -- Jesper Zedlitz Dept. for Computer Science, CAU of Kiel Room 1108Communication Systems Research Group Phone:+49-(0)431-880-7279 Christian-Albrechts-Platz 4 Fax: +49-(0)431-880-7615 24098 Kiel - Germany [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Newbie,T5: Grid limitations (long).
First of all: Overall is Tapestry 5 in general and the the Grid
component in particular an amazing piece of software. So this is *not*
complaints, just an attempt to sort things out, to share my experiences
and check that I understand things correctly.
I have a use case where I'm about to present data in a table. The table
is presenting different databases from time to time, so the db layout
varies. At first glance, I thought the Grid would solve my problems, the
Tapestry 4 did with some tweaks. However, I've run into follwong
limitations:
- The paging policy with a fixed number of numbered pages is hardcoded
and can't be changed. Other policies e. g., overlap between pages or
pages started at random points in the input vector is not possible. This
has been discussed earlier, and is according to HLS a design decision.
- It is not possible to change the overall rendering of a row e. g,, to
to embed each ... in a (e.
g., if a row should wrapped in a microformat).
- It is not possible to change the layout of the table header if you
don't know the name of the column/attribute at compile time. Of course,
you cannot reference an unknown column in the template. But it might be
possible to define a catch all block ("DefaultColumnCell?) which is the
layout for all columns, with provisions to access the current column's
name. Again, this can't be done as of 5.0.11.
- It is not possible to enumerate the properties in the BeanModel data
source (is is possible to list the editable properties, though). Minor
issue, I guess.
Personally, the conclusion is of course to write my own component, no
problem. But maybe some of this or similar info should go into the Wiki,
it would definitely have saved some time for me. There is really a lot
of info what *can* be done with this rather complex and powerful
component. Maybe it's time to add some info about what *can't* be done
with it. Maybe some issue should be a RFE in the JIRA?
Cheers
--Alec
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
