Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

add_forbidden_view can't take a name #897

Closed
bertjwregeer opened this Issue Mar 9, 2013 · 2 comments

Comments

Projects
None yet
2 participants
Owner

bertjwregeer commented Mar 9, 2013

I would like to change the forbidden view depending on the last part of the traversal which can be provided to add_view as name.

This is currently not allowed, which makes it slightly harder to write the logic I require.

Owner

mcdonc commented Mar 25, 2013

FWIW, you can currently work around this now by using config.add_view(context=HTTPForbidden, name='....', permission=NO_PERMISSION_REQUIRED). add_forbidden_view just turns around and does this anyway, and it is fully supported.

name is currently unsupported by add_forbidden_view because views are typically looked up using a combination of context and name. Since add_forbidden_view's context is "pinned" to HTTPForbidden, it's a bit dicey documentation-wise to also encourage users supply a name, as it would imply that every name is unique amongst all name/context combinations, which is typically untrue. For example, if the view name turns out to be "edit" as the result of a traversal, and you have two edit views, one registered for the context Blog and the other registered for the context NuclearArsenal, and you register a forbidden view using the name "edit", it'd be a little weird, because that forbidden view would be invoked when either the NuclearArsenal or Blog view execution was forbidden, or under any circumstance where either the edit view of NuclearArsenal or Blog manually raised an HTTPForbidden.

In any case, you can do it, you just need to spell it in the longer form.

@mcdonc mcdonc closed this Mar 25, 2013

Owner

bertjwregeer commented Mar 25, 2013

@mcdonc However the add_forbidden_view can take a route_name as one of its parameters, which in the case of a hybrid approach would mean that name should be a valid parameter to take. Although, I guess at that point it would be up to the developer to make sure that they don't ever return both a NuclearArsenal and a Blog from the same route_name, although I am not sure that shooting oneself in the foot should be disallowed explicitly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment