What I did was inject (autowire via tapestry-autowire actually) the DataSqueezer into my page and when I needed to construct the model, I just passed it into the constructor.
> Care to share the code? It seems like doing the Squeeze the same as the > EntitySqueezer would be difficult since it delegates to the DataSqueezer > (which I don't know how to get ahold of). > > > -- > Geoff Lane <[EMAIL PROTECTED]> > Ph: 414 290-8031 > > > > -----Original Message----- > From: James Carman [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 06, 2006 10:42 AM > To: 'Tapestry users' > Subject: RE: Tapernate Usage Questions > > 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] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > James Carman, President Carman Consulting, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
