This is related to the behaviour of the For component. Basically, it
tries to find an object with a primary key that has the same string
representation as the one stored in hidden field in the form (the need
to do that is related to updating the data -- see the emails when
Tapestry was in early beta). As a result, you usually have TO
conversions, rather than FROM ones. A FROM is performed only if a
suitable TO is not found.
Also, if you may want to try volatile="true" as an attribute in
contrib:Table (or For) -- that will force the components NOT to perform
primary key lookup. You may get StaleLinkException if you are doing
modications in the form, however, which is why this approach is not
recommended in general.
Sam Gendler wrote:
I have several tables displaying tabulr data that is generated by a
form request. The tables are included in a Form object so that
sorting and paging work correctly - resubmitting the form each time.
However, the data in the table is read-only, and the last thing I need
to do is waste tons of bandwidth sending serialized objects
representing each row to the web browser and back. So I implemented a
PrimaryKeyConverter which just returns a short string instead of an
object. I was surprised to find that while the conversion TO a
primary key was called for every object, the conversion FROM primary
key back to an object was never called during rewind when the form was
resubmitted or a column was sorted. I did eventually notice that when
clicking on another page, however, the primary keys WERE converted
back to objects.
Why is this behaviour so inconsistent? Why aren't my objects looked
up by primary key when sorting or resubmitting a form? On a normal
submit (input type="submit" with a listener on the Form object, not
the submit button), the TableModel is queried for new data, but when
paging through the data, the primary keys are looked up.
Second, is it possible to tell a table in a form to ignore the data
entirely? I have no interest in updating that data - it is a report,
not an edit form, and it seems needlessly wasteful to be doing all
that lookup. For now, I am sending a 1 character string, and in the
lookup, I am returning a statically allocated Map which has keys for
each field of the table, but that is a kludge that I'd love to get rid
of.
The one table that I do have which allows each row to be edited
doesn't do the primary key lookup when I actually submit new data,
anyway. It only does it when I click on a new page, so the effort
seems wholly wasted.
--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]
