The drop-down lists could be taken care of using the squeezer. I implemented a SqueezerPropertySelectionModel class which squeezes the objects into their "values."
-----Original Message----- From: Lane, Geoffrey [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 11:33 AM To: Tapestry users Subject: RE: Tapernate Usage Questions Yes, that does make sense. How would you take care of the case where you have the same Hibernate persistent object in 2 different places? Should we just not be making Collections of objects (such as drop-down lists or table data) Persist, such that Tapernate will re-associate them with the active Hibernate session? Or could we use 'reattach-lock' for those? Thanks for the help James. -- Geoff Lane <[EMAIL PROTECTED]> Ph: 414 290-8031 -----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 10:15 AM To: 'Tapestry users' Subject: RE: Tapernate Usage Questions For reattach-merge, you need to make sure you set your persisted property to null once you're done with it, or else it'll continually merge it in. Does that make sense? -----Original Message----- From: Lane, Geoffrey [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 10:55 AM To: users@tapestry.apache.org Subject: Tapernate Usage Questions 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] --------------------------------------------------------------------- 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]
