Adust the as_table tag to render a pick link if appropriate
The templates are adjusted to pass on a 'reference' value, which
is the url_name of the view from which the entity should be picked.
The as_table (and related) function(s) construct and then pass on
this argument and enable takes_contex so that we have access to the
context of the enclosing template.
We only extract ReferenceProperties that end with '_link_id' since
that is how all RP's are currently named. It is not possible to
create a field with the same name as the RP, as GAE will try to
interpret it's contents as the key of an entity before even calling
any function we can override.
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.