Hi, (I'm new to the list)

We've been porting an application to Tapestry 4 and trying to integrate
Tapernate at the same time to allow us to do lazy-loading of Hibernate
objects, etc. One issue we are having is that Tapernate appears to be
merging old object state back into our Hibernate session after we save
the Hibernate object which in a transaction-per-request will cause the
session to be dirty again and the object to be flushed with the stale
state. If we turn off transaction-per-request, then normally the object
will not be flushed, but the stale values are merged back into the
Hibernate session again which means when the user navigates to the edit
page, they will not see the correct values as they are in the database.

Example Scenario:
We have a Table of Divisions (an organizational unit) with edit links to
navigate to an edit form. Also on every page we have a drop-down list of
all of the Divisions so that a user can change their effective division.

Component 1 - DivisionNavigation - list of available Divisions (in the
Border component so it's on every page)
Component 2 - DivisionTable - table of Divisions with some information
and edit links
Page - Edit Division - set the object from the edit listener in the
DivisonTable and cycle.activate the Edit page

We are marking the collection of Divisions in the DivisionNavigation and
DivsionTable as @Persist("entity") as well as the object that's being
edited in the Page. Is this just wrong? I noticed the newer version of
Tapernate has different persist annotations. Any guidance as to what
would be best for this kind of situation where you might have the object
more than once on a page? Just looking for some guidance (and/or abuse
if we're doing something obviously stupid).

Thanks in advance.


-- 
Geoff Lane <[EMAIL PROTECTED]>
 
 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to