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

# Until model subclassing is a possibility, a mixin class is used to add
# the necessary functions that may be contributed for geographic objects.
class GeoMixin:
    """
    The Geographic Mixin class provides routines for geographic objects,
    however, it is no longer necessary, since all of its previous functions 
    may now be accessed via the GeometryProxy.  This mixin is only provided
    for backwards-compatibility purposes, and will be eventually removed
    (unless the need arises again).
    """
    pass