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]
