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

     1

Third-party code that is *not* part of the application image (the Google App

     2

Engine SDK in trunk/thirdparty/google_appengine, for example) belongs in

     3

trunk/thirdparty.  For third-party code that *is* part of the application

     4

image, see the notes in trunk/app/README.

     5

     6

== THIRD PARTY LICENSES ==

     7

     8

Third-party code must also include a license text file, named LICENSE or

     9

COPYING, in the package subdirectory.  If the third-party package subdirectory

    10

is maintained automatically with a tool such as svn_load_dirs.pl (which

    11

removes files, such as license text files, that were added later to the

    12

"target" directory), place the license text file in the trunk/app directory

    13

and add the package name as a suffix.

    14