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]