No, I definitely for one call for each page, which is why I added a member to my IBasicTableModel which stores the count and returns the same value repeatedly. However, when I moved from FormTable to Table, I started seeing a second call to getCurrentPageRows(), once during rewind and another during render. I can see where this might be necessary if there were form fields in the table, but there aren't. THere should at least be an option. FormTable seems to handle it correctly, at any rate. More importantly, the inability to sort the table while preserving form field values is a definite bug that makes it unusable - a shame since FormTable is deprecated.
--sam On 3/1/06, Daniel Lydiard <[EMAIL PROTECTED]> wrote: > Do you have a log statement for each time getRowCount() is called in your > IBasicTableModel implementation? > > I noticed Table (pretty sure it's TablePages that does it) calls that method > 2+p times, where p is the # of pages in the result set. So if you have << < > 1 2 3 > >> you'll see 5 calls to getRowCount(). I'm just wondering if I'm > the only one, and I'm doing something wrong? > > ----- Original Message ----- > From: "Sam Gendler" <[EMAIL PROTECTED]> > To: "Tapestry users" <[email protected]> > Sent: Wednesday, March 01, 2006 5:24 PM > Subject: Re: update form fields when changing page in table? > > > 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] > > > --------------------------------------------------------------------- > 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]
