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
TEMPLATE NAMESPACES
Templates are placed in a "namespace" subdirectory in the templates directory,
since the templates directory will be added to the Django templates search
path. This allows other packages to extend existing templates without "hiding"
the original template. For example, a template in another Melange application
can extend a template in the SoC framework like this:
{% extends 'soc/some_existing_template.html' %}
without "hiding" the some_existing_template.html for other uses, even if the
derived template is also named some_existing_template.html.
So, please do not put any templates in this soc/templates directory, but only
place them in the soc/templates/soc "namespace" subdirectory.
Different Melange applications should also follow this pattern, to promote
sharing of templates between applications as well. For exmample, the GSoC
Melange application should place its templates in gsoc/templates/gsoc.
MODEL/VIEW TEMPLATE NAMING
View templates are usually named some_view.html for a corresponding someView()
function and SomeViewForm form class. Since SomeView is likely to be a common
View name for multiple Models, Model-specific templates should be placed in
soc/<model>/<view> sub-directories.