[MGNLSTK-577] Make it configurable what classes are included in the freemarker template rendering context Created: 03/Feb/10  Updated: 23/Jan/13  Resolved: 19/Mar/10

Status: Closed
Project: Magnolia Standard Templating Kit (closed)
Component/s: templates
Affects Version/s: 1.2.3
Fix Version/s: 1.3

Type: Improvement Priority: Major
Reporter: Ernst Bunders Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: freemarker, vpro
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to MAGNOLIA-1469 Make Freemarker more configurable thr... Closed
is related to MAGNOLIA-2383 TemplateRenderer should be instantiat... Closed
is related to MAGNOLIA-3087 Allow configuration of shared variabl... Closed
Template:
Acceptance criteria:
Empty
Date of First Response:

 Description   

It would be nice to be able to register classes under the template-renderer en paragraph-renderer configurations, so that those classes would be added to the template rendering context.

STKTemplateRenderer could get a Map property like 'classesToInclude'
it would be nice if modules/standard-templating-kit/template-renderers/stk would be watched, and new classes would be added on the fly through content2bean. STKTemplateRenderer would have to propagate this map to FreemarkerHelper

you could do something like this in FreemarkerHelper:

TemplateHashModel staticModels = wrapper.getStaticModels();
        try {
            for (String name : classesToInclude.keySet()) {
                TemplateHashModel model = (TemplateHashModel) staticModels.get(classesToInclude.get(name));
                map.put(name, model);
            }
        } catch (TemplateModelException e) {
            e.printStackTrace();
        }

That way all static methods of the class are available.



 Comments   
Comment by Philipp Bärfuss [ 04/Feb/10 ]

Nice idea indeed. Today you have to options to achieve the same effect:

a) use the model as a provider for util classes: model.myutil

b) extend the renderer (STKTemplateRenderer for instance) and override the setupContext method

Comment by Magnolia International [ 12/Feb/10 ]

I think this belongs to the main MAGNOLIA project, and can be solved with several, non-contradicting, approaches:

  1. for Freemarker-specific objects/classes: MAGNOLIA-1469 - first need to cleanup the templateLoader configuration (there's an ugly knot to untie there, which was a workaround until MAGNOLIA-2553) - we'll possibly do this for MAGNOLIA-2993
  2. for objects that should be available to all templating engines: something could also be configured in /server/rendering
  3. configure renderers via content2bean: MAGNOLIA-2383

For 2) and 3) we'll need some for of factory/provider interface and implementations, since these objects need to be re-instanciated per request.

Comment by Magnolia International [ 17/Feb/10 ]

Ernst,

I don't know the internals of FreeMarker's staticModels feature, but since MAGNOLIA-3087, this is also possible by registering a sharedVariable in the FreeMarker configuration. (/server/rendering/freemarker/sharedVariables) The only condition being that your utility class must be instantiatable (via Content2Bean/ClassFactory, i.e must be concrete and have an accessible constructor).

Validated with a test: see info.magnolia.freemarker.FreemarkerHelperTest#testCanAccessStaticMethodsOfSharedVariables (in magnolia-core)

Please let me know if this would work you.

To all: regarding my point (2) above - do we want this available for all templating engines - or do we want to keep it implementation-dependent? I guess for JSP, we could push these variables to the ServletContext (which has a similar lifecycle than the Freemarker Configuration object at the moment), but this would somehow pollute the namespace (as other things end up in this context, unrelated to rendering)

Comment by Ernst Bunders [ 18/Feb/10 ]

So you can create properties under 'sharedVariables' that map a class to a name, so an instance of the class is put in the rendering context under 'name'? That sounds fine by me.

i must admit i find server/rendering/freemarker/sharedVariables a bit strange as a location to configure this, as it seems to be a behavior of the renderer class, so i wonder how many people will find it there (perhaps it should be a good idea to mention this feature in the magnolia freemarker primer), lest it will not be a 'hidden feature', as it was to me.

But thanks anyway for the follow up.

regards,

Comment by Magnolia International [ 18/Feb/10 ]

Sure, it will documented (it's just brand new) - it's configured in this location, because it's part of the FreeMarker configuration (i.e these variables are available system-wide to anything that uses FreeMarker, not just template and paragraph renderers)

If you want to try this out, grab the 4.3-m2 jars

Comment by Ernst Bunders [ 19/Feb/10 ]

Ah, just new. That's good. But from a multi-site perspective, is it desirable to configure this stuff globally? Wouldn't it make more sense to be able to configure this for each site? (of course my solution doesn't allow for that either). I guess that there are quite a few things you would like to be able to do on the site level, when you think about it...

Never the less, that is no big deal, and it seems like a fine solution to me.
Thanks,

Comment by Magnolia International [ 19/Feb/10 ]

True, but that's the case for each and every piece of configuration; we'll have to come up with a generic solution at some point; meantime, when this is really needed, use a different instance
(although i'd assume you have different templates for these site-specific things, so you could just register those objects with different names. Or make those sharedVariable objects site-aware)

Comment by Magnolia International [ 19/Mar/10 ]

Solved by MAGNOLIA-3087.

shareVariables can hold objects that have static-only methods or not. These objects should be stateless, since rendering can be used simultaneously by several threads.

Generated at Mon Feb 12 07:28:22 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.