Ben, Sorry I didn't get back to you. But, with respect to the persistence strategy, that's about right. I think you've got it. The squeezer does squeeze the entities based on their persistent identity also.
James -----Original Message----- From: Ben Dotte [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 03, 2006 4:34 PM To: Tapestry users Subject: RE: Tapernate Questions In thinking about this some more and searching the mailing list, I think I have come to a more logical conclusion about how Tapernate works. But again, it would be great if someone familiar with the project could confirm/deny this: The "entity" persistence strategy is just used to load objects from the database back into the Hibernate session at the beginning of each request. Say the user submits a form with some incorrect data. All of the fields that pass validation get set on the object being edited, while all fields that do not pass validation are held in the validation delegate. Then when the render cycle occurs, it pulls valid data from the object (which has not yet been committed) and invalid data from the validation delegate. Then AFTER the render cycle, the whole transaction gets rolled back. Hence, no user-entered data on the form was lost, AND nothing got committed to the database. That certainly sounds like a satisfying explanation to me, it would be great if it was true. Ben -----Original Message----- From: Ben Dotte [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 03, 2006 11:19 AM To: Tapestry users Subject: Tapernate Questions I was just taking a look at Tapernate for the first time and I was hoping James or someone familiar with it could verify my understanding of how it works and clear up a few things: - Persistent properties are squeezed/unsqueezed based on their Hibernate session identity. - The @Persist("entity") persistence strategy differs from regular session persistence in that it merges persistent objects into the Hibernate session in getStoredChanges(). From the docs, getStoredChanges() usually happens when you want to roll back a page to a previous state. If that is the case, how does Tapestry know you want to roll a page back to a previous state (is it when the validation delegate fails or something)? Or am I misunderstanding what the "entity" strategy is intended to do? - In the Tapernate demo, object properties are modified directly and if there is a problem of some sort, the transaction is rolled back. This way all changes made by the user are committed or rolled back. This seems related to the "entity" strategy in that I would not want partially successful submissions persisted to the database, but I also don't want to lose any user input (and the validation delegate only stores input from those fields with invalid input). So then are the successful changes in a partially successful submission stored in the object in the Hibernate session? Thanks in advance for any info, this looks like a great library. Ben --------------------------------------------------------------------- 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]
