[PEAK] Re: dispatch rules based of the current scope.

[Phillip J. Eby]

At 07:48 AM 3/20/2006 +0100, Elvelind Grandin wrote:
>Well. let me give you an exemple.
>
>right now the user might do something like
>@expose(template="..", as_format="..", accept_format="..")
>def foo.
>
>this would set up some dispatch rules for the templatet based of
>as_format and accept_format.  now I want to have an custome_rule
>arguement where the user might do "in_group(admin) and request.foo or
>...)

My suggestion would be to have 'in_group(user,admin)' (where 'user' is an 
argument to the function) or 'admin.is_member()', and 'get_request().foo'.

Or, make 'request' and 'in_group' be arguments to the function.  Or have a 
context argument that has methods for all the things you want to test.

The truth is, your functions aren't going to be inlined by RuleDispatch, so 
it doesn't know the meaning of your 'in_group()' rule unless you tell 
it.  It just gets treated as an arbitrary boolean expression, with no way 
to determine precedence compared to other such expressions.

There is a hook for custom expansion of such functions, though, which is 
used for things like turning 'isinstance()' expressions into low-level 
rules.  Indeed, any boolean pure function that can be recognized by its 
identity, can be translated into an arbitrary criterial expression.  The 
criterial expression can then be indexed the way other conditions are.

This is not as complex as completely overriding the compilation process, 
but will still require you to learn a bit about the internal structure and 
possibly define a new criterion type.  The benefit is that you may be able 
to "teach" RuleDispatch
that rules specific to a user are "more specific" than rules that apply to 
a whole group.