You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by manuel aldana <al...@gmx.de> on 2009/02/16 01:10:13 UTC
[Dispatcher] unclarity for interface contract
Hi,
for Dispatcher
(http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/services/Dispatcher.html)
the contract of return value is:
---
@return true if a response was delivered, false if the dispatcher did
not handle the request (and a search for a handler should continue)
---
For understanding I am having problems with 'and a search for a handler
should continue' in case false was returned. Reading this, true means
that dispatching should be stopped and no other Dispatchers should be
called.
But how about a Dispatcher has done its work and wants to pass further
work to more dispatchers (something like dispatcher-chaining, where each
Dispatcher does something more to the Response).
--
manuel aldana
aldana@gmx.de
software-engineering blog: http://www.aldana-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [Dispatcher] unclarity for interface contract
Posted by manuel aldana <al...@gmx.de>.
>> But how about a Dispatcher has done its work and wants to pass
>> further work to more dispatchers (something like dispatcher-chaining,
>> where each Dispatcher does something more to the Response).
>
> I guess a RequestFilter would be a better fit for this kind of
> scenario. ;)
OK, but in tapestry codebase when do you choose RequestFilter or a
Dispatcher? Looking at implementing classes (Dispatcher vs. Filter) I
couldn't find a real distinction...
--
manuel aldana
aldana@gmx.de
software-engineering blog: http://www.aldana-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [Dispatcher] unclarity for interface contract
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sun, 15 Feb 2009 21:44:54 -0300, manuel aldana <al...@gmx.de> escreveu:
> OK, but in tapestry codebase when do you choose RequestFilter or a
> Dispatcher? Looking at implementing classes (Dispatcher vs. Filter) I
> couldn't find a real distinction...
They're very different. A Dispatcher is analogous to a servlet, while a
RequestFilter is analogous to a servlet filter. A Dispatcher serves to
generate a response, so it doesn't make sense to chain them. A
RequestFilter serves do some processing before and/or after a request
handling, not handle the request itself.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [Dispatcher] unclarity for interface contract
Posted by manuel aldana <al...@gmx.de>.
>> But how about a Dispatcher has done its work and wants to pass
>> further work to more dispatchers (something like dispatcher-chaining,
>> where each Dispatcher does something more to the Response).
>
> I guess a RequestFilter would be a better fit for this kind of
> scenario. ;)
OK, but in tapestry codebase when do you choose RequestFilter or a
Dispatcher? Looking at implementing classes (Dispatcher vs. Filter) I
couldn't find a real distinction...
--
manuel aldana
aldana@gmx.de
software-engineering blog: http://www.aldana-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [Dispatcher] unclarity for interface contract
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sun, 15 Feb 2009 21:10:13 -0300, manuel aldana <al...@gmx.de> escreveu:
> But how about a Dispatcher has done its work and wants to pass further
> work to more dispatchers (something like dispatcher-chaining, where each
> Dispatcher does something more to the Response).
I guess a RequestFilter would be a better fit for this kind of scenario. ;)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org