On 10/26/06, Don Brown <[EMAIL PROTECTED]> wrote:
Hmm... I suppose you could create a selector result, which would
delegate handling to other results, but how would those results be
configured?
true... this would not be extendible
As for the implementation of selectors, I'm thinking of something like:
public interface ResultSelector {
public ResultConfig chooseResult(String resultCode, List
matchingResultConfigs, ActionInvocation inv);
}
then you could have:
* o.a.s.dispatcher.UserAgentResultSelector
* o.a.s.dispatcher.ContentTypeResultSelector
* o.a.s.dispatcher.RequestAttributeResultSelector
and so on. Perhaps these would be executed in a chain, such that the
user agent selector would get the first shot, but if not found, return
null, so the content type selector is called next, and so on.
This may be a good start, but how will this deal with the case when
the result depends on 2 (or more conditions)?
./alex
--
.w( the_mindstorm )p.
Don
Alexandru Popescu wrote:
> At the first glance the idea looks interesting, but I am wondering if
> this is not just a matter of having a custom result type; because I
> cannot image a way to cover any possible "when" case.
>
> ./alex
> --
> .w( the_mindstorm )p.
>
>> Don
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
