Skip to content
This repository

module template api #265

kaos opened this Issue November 22, 2011 · 9 comments

2 participants

Andreas Stenius Maas-Maarten Zeeman
Andreas Stenius

There are a number of templates floating around that are being referenced across module boundaries.
I'd like to call these templates api templates, since they're meant to be included from other modules templates.

These api templates gives a dependency between modules that isn't really clear.
Arjan made a commit to solve one of those (by adding an empty _language_attrs.tpl in the admin module.. but there a more, and this approach doesn't feel quite right).

So, I suggest that we add another level of indirection in the templates directory, so we have private and public templates, and that only templates that are made public may be included from other modules.

This serves another purpose too, by making it clear which templates exist that are suitable for other modules to include. For instance the admin module has a number of such templates, but they're quite hard to find unless you know about them.

And last, what to do when trying to include a missing template. There are a number of scenarios:

  1. The template doesn't exist
  2. The template is found from a disabled module
  3. The template is private

A new flag could be added to the include tag, specifying if a missing/private template should silently be ignored, generate a warning or fail with an error message.

Update (2011-11-24)

After brainstorming with Maas, I realize the above mixed the problem with a proposed solution making it unclear what is what.

The problem has been further clarified as:

a included template from a disabled module results in a notice about a template not being found.

And I'm looking for a general solution that doesn't require one to add arbitrary empty templates from client modules.
The proposed include tag works regardless of the inclusion of a public/private indirection, and would perhaps be the better approach.

Maas-Maarten Zeeman

Another annoyance is that adding templates to your site can totally screw up the admin interface.

The simple priority based include mechanism has its merits, but can lead to strange situations that modules/sites include seemingly unrelated things from each other.

Would a public/private mechanism also prevent this problem?

Andreas Stenius
Maas-Maarten Zeeman

Recently my colleague changed _language_select.tpl in the site template directory to make a list with languages + images instead of a select. Only to later on discover that the admin interface is screwed up...

He didn't understand why this was the case... His reasoning was that the admin interface should always pick the closest matching template instead of just look at the prio.

Andreas Stenius

What is closest matching... ?
And how would you override such a template, in case you wanted to do that... ?

Maas-Maarten Zeeman

I'm thinking out loud here. Hopefully it will finally result in something usable :-)

Imagine you have the zotonic tree. In that tree are containers, modules and sites. Sites are hierarchical containers, because they can contain sub-modules.

Now, when you include a template... look into own container first, not found, look one level up .. etc, still not found, find the template from the module with the highest prio. That way you have containment of the include operation, which is nice for modularity.

Now for the language_switch template this means that it is found by admin because it is in the zotonic container. It doesn't find the template from the site with a higher prio.

I realize this is quite a different model from the way currently templates, scomps, filters and such are selected. Overriding in this model must be done explicitly.

Andreas Stenius
Maas-Maarten Zeeman

And the brainstorm continues. :-) After giving it some more thought I must say that I quite like the current prio based mechanism. Simple to understand and en simple to understand once explained. No magic. Well at least not complicated magic...

Personally I don't care if we would have private and public templates. For documentation it is nice, but then I also would like to know about the arguments needed by the template.

For me that leaves just one issue. I want to be able to bypass the implicit lookup magic. Maybe with something like this:

{% include "_language_switch.tpl" from="mod_translation" %}

And from erlang:

z_template:render("_language_switch.tpl", mod_translation, Context),

This would allow one to bypass the lookup mechanism and make a dependency explicitly known.


Andreas Stenius
Andreas Stenius kaos closed this December 04, 2012
Andreas Stenius

Closed in favor of #471.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.