Yeah, but for my EntitySqueezer, you have to pick a common superclass for your entities so the squeezer can say "I can squeeze these types of objects." > Hi James, > > from my understanding the current implementation is already > something like a pipeline: Every squeezer gets asked if he > is able to squeeze the object by checking the class he supports. > > So you just want to move the "logic" and decision from the upper > level to the squeezers or didn't I get it? > > Cheers, > Andreas > > On 27. Apr 2006 - 09:15:00, James Carman wrote: > | All, > | > | I have a suggestion on how we can improve the "squeezer" framework in > | Tapestry. Rather than the squeezer saying "I can squeeze these type of > | objects" by returning a common superclass, I suggest we create a > | SqueezerPipeline. Each squeezer (filter) in the pipeline would be given > a > | chance to handle the object that needs to be squeezed. If it doesn't > want > | to squeeze it, then it just passes it to the next object in the pipeline > | (the next squeezer). So, for my entity squeezer, I could determine, via > | the HiveMind API, whether I can squeeze it. If I can't, then I just > pass > | it on down the line. This would help if I try to squeeze an object that > | hasn't been persisted yet. In that case, I just have to pass it down > the > | line to let the serializable squeezer do it. The end of the line could > be > | a squeezer that just throws an exception saying that no squeezer could > be > | found for type blah blah blah. I think this would be much more robust. > | What do you think? > > > --------------------------------------------------------------------- > 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]
