> 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 <[email protected]>: > On Thu, 14 Feb 2013 08:29:53 -0200, Denis Stepanov <[email protected]> > 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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
