On Sun, 2012-02-05 at 11:45 +0100, Benjamin Hepp wrote: > I tried to narrow down my initial problem a bit more and finally got to > the cause: > > So as I said I have something like > > @view_defaults(context=A, name='update') > class UpdateHandler(object): > ... > @view_config(predicates...) > def update1(self): > ... > > @view_config(context=B, request_param='id=123') > def update2(self): > ... > > And this is what happens: > When the update2 method gets registered as a view_callable for contexts > of type B, update2 will the view_callable that is found whenever the > view_name is 'update' and the context is of type B. Only afterwards the > other predicates (e.g. like request_param) get checked and if they fail, > then there is just no view available. > > Initially I thought that the context is a predicate in the same way as > all the other predicates. Without looking into the code I couldn't have > figured out the above from the docs. So maybe there should be a special > category for the context and the view name, like 'primary predicates' > and 'secondary predicates' for the rest? > > Or do you think it might be worthwhile to implement a 'complete' search > through all registered views that could match a request? Would you > consider to include such a patch into pyramid? >
There are some suggestions about how to do that here: https://github.com/Pylons/pyramid/issues/409 > Cheers, > Benjamin > > > On 2/4/12 3:47 PM, benjamin.hepp wrote: > > So I though a bit about it and what I actually would like to have is > > something like this: > > https://gist.github.com/1738249 > > > > So what I would imagine is that a method decorated with > > @view_controller is only getting a @view_config when it's class is > > actually decorated with @view_controller. This makes it able to define > > default view methods in a base class that don't get added by > > config.scan. > > > > I also want the cleanup method to be called after a view method has > > returned (if it exists). Of course a method @view_controller should > > only overwrite the predicates for this single method. > > > > What do you think about this? Would you rather go with implementing > > the processing logic seperated from the view logic? e.g. the view > > logic could just look for a processing class that can handle the > > resource. Though this would probably kind of duplicate the view lookup > > system. Or would you go with a base class, e.g. ViewController from > > which one can inherit and then decorate the methods? > > > > Cheers, > > Benjamin > > > > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
