You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by James Carman <ja...@carmanconsulting.com> on 2006/04/27 15:15:00 UTC
Squeezer Pipeline?
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Squeezer Pipeline?
Posted by James Carman <ja...@carmanconsulting.com>.
It places an unnecessary restriction on my domain model. In order to use
the squeezer, I have to register it to handle exactly one type (and its
subclasses/implementing classes). My domain model may not have a common
superclass. Of course, my domain model does, but if I want the squeezer
to be generally applicable, then this is a restriction.
> On 27. Apr 2006 - 09:23:30, James Carman wrote:
> | 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."
>
> Hm, I don't see the problem with this...
> But well, very probably I just don't know enough about the Tapestry
> internals
> so I think I'll be quiet on this topic from now on ;)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
James Carman, President
Carman Consulting, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Squeezer Pipeline?
Posted by Andreas Bulling <sp...@phoenix.hadiko.de>.
On 27. Apr 2006 - 09:23:30, James Carman wrote:
| 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."
Hm, I don't see the problem with this...
But well, very probably I just don't know enough about the Tapestry internals
so I think I'll be quiet on this topic from now on ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Squeezer Pipeline?
Posted by James Carman <ja...@carmanconsulting.com>.
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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
James Carman, President
Carman Consulting, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Squeezer Pipeline?
Posted by Andreas Bulling <sp...@phoenix.hadiko.de>.
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Squeezer Pipeline?
Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <ja...@carmanconsulting.com> 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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
RE: Squeezer Pipeline?
Posted by James Carman <ja...@carmanconsulting.com>.
So, what would it take to implement something like this? I really think
it's a necessity (since I need it). :-)
-----Original Message-----
From: James Carman [mailto:james@carmanconsulting.com]
Sent: Thursday, April 27, 2006 9:15 AM
To: tapestry-dev@jakarta.apache.org; tapestry-user@jakarta.apache.org
Subject: Squeezer Pipeline?
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org