I prefer having my objects re-attached when possible. It's a slipperly slope to go down with hibernate when you have to start thinking about which members have been lazily initialized and which have not.
On 5/25/06, James Carman <[EMAIL PROTECTED]> wrote:
Well, you don't have to auto-reattach them if you don't want. -----Original Message----- From: Ted Steen [mailto:[EMAIL PROTECTED] Sent: Thursday, May 25, 2006 2:50 PM To: Tapestry users Subject: Re: Tapernate "squeezer" refactored... Absolutely, that would really suck. As I said, it is really redundant. What are your thoughts on the edit-domain-objects-problem? I can see, in your example, that you simply setRollbackOnly(); when something didn't validate, but I can't say that I think it is a clean solution. What do you think of the idea of just working on detached objects when editing? What do other people in this list do in this situation? 2006/5/25, James Carman <[EMAIL PROTECTED]>: > Yes, but if you edit a copy of the domain object, then you start to develop > the "parallel hierarchy" code smell (assuming you'd create a "value object" > for each type of domain object). > > > -----Original Message----- > From: Ted Steen [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 25, 2006 2:29 PM > To: Tapestry users > Subject: Re: Tapernate "squeezer" refactored... > > Ah, this is a lot cleaner than the previous solution with DataClasses. > The URLs are prettier too, nice work! > > The problem with editing a talked about in another thread could be > solved by not working on the domain object, but a copy of the domain > object, or individual getters and setters for every property of the > object. > Problem is that it is so redundant.. :/ > > Another thought was to work on detached objects when editing, and > explicitly session.save(...) them when all is validated and ready to > be saved. > > I can't say that I have thought this through as much as I should but.. :) > > 2006/5/25, James Carman <[EMAIL PROTECTED]>: > > Oh, this feature, the squeezer pipeline has been submitted as a patch for > > Tapestry 4.1. So, in the future, I'll probably just re-implement my > filter > > using the Tapestry 4.1 API as opposed to the Tapernate API. Either way, > > there should be no impact to client code (unless you write your own > filter). > > > > -----Original Message----- > > From: James Carman [mailto:[EMAIL PROTECTED] > > Sent: Thursday, May 25, 2006 11:29 AM > > To: 'Tapestry users' > > Subject: Tapernate "squeezer" refactored... > > > > All, > > > > Tapernate's entity "squeezer" has been refactored. No longer do you need > to > > tell it what your "data class" (the common entity superclass/interface) > is. > > Tapernate turns the data squeezer service into a pipeline and puts its > > EntitySqueezerFilter into the pipeline. If it can't squeeze the object > (the > > object isn't persistent), then it just lets the rest of the pipeline take > > care of it. If it can squeeze it, it does. The squeezed string will look > > something like this (from the example application): > > > > HIBRN8:0::l1 > > > > The "HIBER8" part is a token that tells me that I squeezed this object. > The > > '0' is an abbreviation for the entity name (just print a number rather > than > > printing out com.mycompany.domain.entity.MyDomainClass). And, the "l1" is > > how the rest of the pipeline squeezes my long (value 1). Enjoy! > > > > James > > > > p.s. Yes, I'm going to move it! > > > > > > > > --------------------------------------------------------------------- > > 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] > > > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
