[MAGNOLIA-1482] Templates stored in repository Created: 25/Apr/07 Updated: 23/May/16 Resolved: 26/Jan/09 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | templating |
| Affects Version/s: | None |
| Fix Version/s: | 4.0 |
| Type: | New Feature | Priority: | Major |
| Reporter: | Magnolia International | Assignee: | Magnolia International |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Template: |
|
||||||||||||||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||||||||||
| Description |
|
At the moment, templates (ie. paragraph or pages) are stored on the filesystem (jsp) or the classpath (freemarker) Having them on the repo (a specific workspace) would allow
This seems pretty easy to implement for freemarker templates (implement a new freemarker.cache.TemplateLoader), with one warning though: since freemarker caches the result of its template parsing, loading the templates should probably occur in an acl-unaware way, i.e we should not try to restrict who/what can render certain templates. (of course, it's a different story for editing them through the admin interface, where we definitely want to use ACLs to determine who can view the templates source and modify them) Doing the same thing for JSPs seems rather cumbersome (one could imagine writing the repo content to the filesystem on creation/activation of node), and I'm not sure we should encourage this. |
| Comments |
| Comment by Magnolia International [ 12/Sep/08 ] |
|
one thing i'd love to see here is an import function that lets one import a template from fs OR classpath into the repo, to apply customizations as needed. |
| Comment by Magnolia International [ 06/Oct/08 ] |
|
note for later: loaders like the WebappContextTemplateLoader could be wrapped in a "LazyWebappContextTemplateLoader" - so no need for checking the state of the template loaders for each call in FreemarkerHelper, and actual working observation/reloading/changing of the TLs |
| Comment by Jan Haderka [ 06/Oct/08 ] |
|
How do you think it should work? There is no setServletContext() method on WebappContextTemplateLoader would it be safe to assume servlet context never changes and cache instance of the WCTL with the SC as it was when loaded first time? This might not work when server decides to temporarily increase number of instances of default servlet due to load and discard them later. |
| Comment by Magnolia International [ 06/Oct/08 ] |
.. which is why you have a lazy wrapper, which will only instanciate the wrapped WebappContextTemplateLoader once a WebappCtx is available. SC never "changes", afaik, you can keep that reference. I don't see the connection with an increase of the number of servlets made by the container behind the scenes. |
| Comment by Jan Haderka [ 07/Oct/08 ] |
|
You are right of course ... dunno what I was thinking. |
| Comment by Jan Haderka [ 08/Oct/08 ] |
|
To summarize the security related implementation details:
|
| Comment by Magnolia International [ 10/Dec/08 ] |
|
Also see MGNLINTEMPL |
| Comment by Magnolia International [ 20/Jan/09 ] |
|
I might try to put in some improvements for 4.0, if not, I'll split another issue for 4.1 |
| Comment by Magnolia International [ 26/Jan/09 ] |
|
This is |