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?
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
>
signature.asc
Description: OpenPGP digital signature
