You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Kovács István <ko...@gmail.com> on 2007/03/16 09:36:27 UTC

Avoiding serialization

Dear All,

I have a toy application, composed of a View and an Edit screen. They
work by looping through objects from a "database" with a Loop component,
setting a property in the page instance to the current element, and
extracting some of its fields. The View screen simply inserts extracted
fields (Strings) into the HTML, while the Edit screen puts them into
textfields. I only have a few objects whose fields are presented as a
table, this kind of editing, with a single Submit button, is more
convenient than having a separate screen to edit individual objects.

When the submit button is clicked, the objects in the database are not
updated. This is because the Loop cycles through the deserialised
objects, not the originals. I got around that by modifying the
setCurrentItem(Item item) method in the Edit page class to extract the
key from its parameter, and set the current item to an object retrieved
from the database using that key. Then the setters are run on the
database object and the page works.

I have two problems with this:
- this is less than elegant, and kind of defeats the purpose of having a
nice Loop component that can cycle through collections; I might as well
return database indexes instead - but that's not very OO;
- the HTML page is large, polluted with serialized Java objects. They
are not very large in my case, but this is a toy project (and in a real
project, making sure everything is serializable may not be a trivial task).

For Tapestry 4, Kent Tong's excellent book, "Enjoying Web Development
with Tapestry" lists a solution to both problems. Honestly, I think my
modified setCurrentItem solution is simpler than his, based on an
InvokeListener and performing some magic in the rewind phase. It is my
understanding that Tapestry 5 does this differently (no rewind phase?)
anyway. My solution can have drawbacks I'm not aware of - could
someone please point them out?
Kent's solution to the other problem (storing just the key - and maybe
a Hibernate version number so stale objects can be detected) was
providing a converter. This has been replaced by encoders (encoder
parameter of the Loop component), right?

TIA,
Kofa

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org