Sverre Rabbelier <srabbelier@gmail.com> [Sat, 06 Dec 2008 14:24:50 +0000] rev 681
Cleanups in group and program
The missing super call in group prevented the scope from being set
as it should be.
Patch by: Sverre Rabbelier
Sverre Rabbelier <srabbelier@gmail.com> [Sat, 06 Dec 2008 14:24:26 +0000] rev 680
Added a new create regexp in urls for just scope_path
Now that scope_path is properly defined we can add a url matching
just the scope path. This allows some other custom create regexps to
be removed/rewritten.
Note: It needs to be -after- the full key_name regexp, since for
arbitrarily nested scopes it would always match as just scope_path,
even if there are other fields needed after the scope.
Patch by: Sverre Rabbelier
Sverre Rabbelier <srabbelier@gmail.com> [Sat, 06 Dec 2008 14:23:53 +0000] rev 679
Introduce dynamic scope_path regexps
Instead of relying on scope_path's being "one slash deep", we should
instead allow for either:
1. scope_paths that have a pre-defined depth
2. scope_paths that can be arbitrarily deep
We achieve 1 by setting an entities scope_logic to another logic
module. We then recursively call getScopeDepth until we get to the
topmost entity (that is, an unscoped entity).
A little different is the solution to 2, since some entities can have
an arbitrarily deep scope (such as Documents), we need to have some
way of signaling this to getScopePattern. A clean solution is to
return None, rather than a number. If None is returned, the
SCOPE_PATH_ARG_PATTERN is returned as regexp instead, which will
match an arbitrarily deeply nested scope.
The solution for 2 requires that we return None somewhere in the
scope_logic chain, the most straight forward method to do so is to
override getScopeDepth anywhere such a scope is needed and make it
return None. A more elegant solution however, is to set the
scope_logic to that module in all entities that require it.
Patch by: Sverre Rabbelier