Actually, there seems to be a bug in @Table in tapestry 4, compared to using a FormTable (which results in at least one deprecation warning at runtime). When I put a regular Table inside a form in Tap4, going through the pages does work correctly, preserving all form values. However, selecting a column header in order to change the sort order causes the form to get reinitialized to default values. Conversely a FormTable allows sorting to function correctly while preserving the form values. Even worse, however, the regular Table causes the count query and the data query to execute during rewind AND during rendering, whereas the FormTable causes the count query to execute during both rewind and render, but at least the data query is only executed during the render stage, saving a lot of data transfer cycles on the web and db servers.
My IBasicTableModel stores the result of the count query, so I assume getModel() is being called twice, since it always instantiates a new IBasicTableModel when called. I could fix that by keeping it around after instantiation. But surely the queries shouldn't be executed twice in the Table, and sorting should definitely work. --sam On 3/1/06, Sam Gendler <[EMAIL PROTECTED]> wrote: > On 3/1/06, Robert Zeigler <[EMAIL PROTECTED]> wrote: > > (Note: I'm assuming that you're using contrib:Table). Why not stick your > > table inside the form? > > Yeah, I just figured it out. I started thinking about how I would > solve the problem if I were implementing table and decided that > autodetecting the presence of a surrounding form would be the way to > go. I tried it, and lo and behold... > > I'm on day 3 of Tapestry development and every day I am more and more > pleased with my decision to use Tapestry, because of things like the > above. > > --sam > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
