This brings up some questions.. If I work directly on my domain model in the "tapestry layer", then data on forms that do _not_ validate, get persisted. This on the other hand could be solved by calling setRollBackOnly() if the form didn't validate.
But if the edited object get passed around on different pages (e.g. some kind of preview service or multiple step form wizard etc..) the object gets saved outside of my control. I want my altered objects to go through my business layer before they get persisted. Any suggestions here? I need to settle for a design that gives me total control of what is persisted and what is not. Maybe I shouldn't have domain objects in my tapestry layer...? 2006/5/24, James Carman <[EMAIL PROTECTED]>:
Yes, that's correct. Using an ORM requires a different mindset. In fact, there was a pretty interesting post on TheServerSide.com yesterday about this very topic: http://www.theserverside.com/news/thread.tss?thread_id=40581 -----Original Message----- From: Marcus Matèrn [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 1:28 PM To: Tapestry users Subject: Re: New version of Tapernate... One question, If I retrieve an object from my DAO and change something in that object without doing a session.update(...), the change will be persisted (to the DB). Is this the way it should work (not having to do a manual update) ? public Product getProduct() { Product product; product = getProductAccess().getProduct(getId()); product.setContent("this text will be written to DB"); return product; } Marcus On 5/24/06, Marcus Matèrn <[EMAIL PROTECTED]> wrote: > Henri, > http://www.carmanconsulting.com/svn/public/ > > > James, I'm also very greatful. Thanks! > > > > On 5/24/06, Henri Dupre <[EMAIL PROTECTED]> wrote: > > Hi James, > > > > > > On 5/24/06, James Carman <[EMAIL PROTECTED]> wrote: > > > > > > > > > 2. Taperate now has support for three types of property persistence, > > > reattach-merge (used to be called "entity"), reattach-lock, and > > > reattach-update, corresponding to the three different types of reattach > > > strategies. You can choose which one you want to use for your situation > > > (reattach-update doesn't support POJO rollback, though since Hibernate > > > will > > > not give me the previous values for some reason) giving you more > > > fine-grained control. > > > > > > 3. The spring.hibernate3 module now supports an "interceptor pipeline." > > > So, you can add as many interceptor "filters" as you wish, which can do > > > various actions (logging, auditing, etc.). The POJO rollback is > > > implemented > > > as an interceptor filter. > > > > > > Tapernate will move soon. I finally got the Maven2 build to work, so now > > > I > > > just have to upload it and set up some docs for it. For those of you who > > > are currently using Tapernate, you don't have to upgrade, but it's > > > strongly > > > suggested. > > > > > > Again, where is tapernate located? I searched last time on Howard's site > > where he has tapestry-spring and other small projects but I couldn't find > > your project. > > > > I'd be interested to know more about your different reattach strategies... > > Do you understand in details which one to use when? > > To me "lock" should always be used unless you have duplicate objects, right? > > And having duplicate objects is not good in hibernate, if I get it right? > > > > I like the idea of an interceptor pipeline... Would it allow easily to > > monitor performance of DAO methods? > > > > Thanks, > > > > Henri. > > > > > --------------------------------------------------------------------- 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]
-- /ted --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
