I like it. It's the same exact approach I use to choose which type of response builder to use for a given request. (Ie normal html markup / json / prototype / dojo / etc.. )
On 4/27/06, James Carman <[EMAIL PROTECTED]> 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? > > James Carman > > --------------------------------------------------------------------- > 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.
