[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: |
|
||||||||||||||||
| 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' 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:
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 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. |
| 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 |
| Comment by Magnolia International [ 19/Mar/10 ] |
|
Solved by 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. |