Default jinja macros to be imported at course level about relate HOT 8 OPEN

This is a good idea. At the same time, I am wondering where these default macros (or really code snippets to be included by default) should live. The obvious solution would be to have a "magical" file somewhere in the git repository that gets included by default. I am little bit worried about the discoverability of this approach, however. For example, since relate already integrates information from the repository and the database, there is a bit of a feel that information just gets pulled "at random" from various sources. This would add one more layer of that. Any suggestions/thoughts?

from relate.

Sorry for my tentative suggestion. I had previously imagine if we can add something like allowed attribute (list type) in the course.yml above chunks, which will be treated as a global attribute when rendering the pages. Something like:

name: Sample Course
number: CS123
run: Fall 2014
default_macro:
    - {% from foo.jinja import bar1, bar2 %}
    - {% from foo2.jinja import bar3, bar4 %}

chunks:

However, I must admit that I do not fully grasp Django, Jinja2 and the mechanism of Relate, the idea is not mature or totally not applicable.

BTW: Maybe this article is helpful.

from relate.

I'm not completely comfortable putting something like this in just yet, I would still like to let the idea "simmer" a little so that I have more time to form an opinion.

One particular concern is that there are two different Jinja contexts, one for the overall YAML document, and then another for each of the text blocks that contain course markup. I am sort of resisting having default macros that apply at the YAML document level, because I believe that forcing explicit inclusion once per document is not too onerous. At the level of the individual markup chunks however, I can see the convenience, but magical inclusion of some macro snippet behind the user's back still doesn't entirely feel discoverable.

The article you linked does look helpful by the way.

from relate.

You are right. I agree with you especially when I found that I need to import a frequently used macro into the caller of another macro.

from relate.

Let's leave it sit and come back to it later.

from relate.

OK.

from relate.

It seems that using Jinja macro is a very expensive operation, although it can greatly reduce duplicate and complex template code. Can I get a conclusion that we'd better not use Jinja macro for frequently visited pages?

from relate.

If you enable caching, then the expense is incurred once, so it should not be a big deal. Without caching, page rendering is pretty expensive, although I think Markdown is more expensive than Jinja. I could be wrong on that though.

from relate.