tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Stepanov <denis.stepa...@gmail.com>
Subject Re: [VOTE] TAP5-2070 Implement logic to handle requests to unknown URL as 404
Date Thu, 14 Feb 2013 12:09:57 GMT

> Are you suggesting a service to handle that, so we can override it if needed? If yes,
I agree. If not, I don't know what you're talking about.

Yes

> I don't think this is a good idea at all. In addition, what we're trying to solve here
is exactly the problem of handling context values which aren't handled and Tapestry can infer
they should be a 404, so your solution isn't much of a solution of the problem to me. We're
trying to solve a problem and creating another event and logic just adds complexity instead
of simplifying stuff.

I understand, for me it's more simplistic to have a different event than switching behaviour
by an annotation.  

Should be 404 raised in a case, when there are less parameters that there are required?

Denis

Feb 14, 2013 v 12:16 PM, Thiago H de Paula Figueiredo <thiagohp@gmail.com>:

> On Thu, 14 Feb 2013 08:29:53 -0200, Denis Stepanov <denis.stepanov@gmail.com> wrote:
> 
>> I like the idea also but implementation is not perfect.
>> 
>> - You're using instanceof to check if context is empty, but I would say correct way
is to check the size of the context.
> 
> Agreed.
> 
>> - Not-handled response logic should be abstract, what if someone wants a different
response code or a different behaviour?
> 
> Are you suggesting a service to handle that, so we can override it if needed? If yes,
I agree. If not, I don't know what you're talking about.
> 
>> - I don't like that you can only have one or another, what if I want one page with
onactivate exactly matching event and another page to have the old behaviour.
> 
> That could be solved with an annotation.
> 
>> Could it be solved by introducing something like onRequiredActivate? If page handles
event "requredActivate" (ComponentModel#handlesEvent) use the new behaviour otherwise the
old one.
> 
> I don't think this is a good idea at all. In addition, what we're trying to solve here
is exactly the problem of handling context values which aren't handled and Tapestry can infer
they should be a 404, so your solution isn't much of a solution of the problem to me. We're
trying to solve a problem and creating another event and logic just adds complexity instead
of simplifying stuff.
> 
> -- 
> Thiago H. de Paula Figueiredo
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Mime
View raw message