I mean that he doesn't have to have Tapernate reattach them for him. He can work with the detached objects and choose when to reattach them manually. But, as you point out, I don't like to have to think about it. It's nice that they're automatically reattached for me. :-)
-----Original Message----- From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] Sent: Thursday, May 25, 2006 2:56 PM To: Tapestry users Subject: Re: Tapernate "squeezer" refactored... 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
