templates in separate workspace (freemarker) (MGNLINTEMPL-1)

[MGNLINTEMPL-4] templates in workspace: extract templates to the workspace Created: 30/Sep/08  Updated: 02/Dec/13  Resolved: 20/Oct/08

Status: Closed
Project: Magnolia In-place templating Module (closed)
Component/s: base system
Affects Version/s: 1.0
Fix Version/s: 1.0

Type: Sub-task Priority: Major
Reporter: Philipp Bärfuss Assignee: Jan Haderka
Resolution: Fixed Votes: 0
Labels: mme_sprint2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Date of First Response:

 Description   

An install task extracts all the templates from the classpath to the template workspace. Optionally ensure that changed templates are not overwritten on an update but the unchanged are.



 Comments   
Comment by Jan Haderka [ 08/Oct/08 ]

Added flag to enable/disable serving of templates per template. However to solve future upgrade issues I'll add additional "autoImport" flag. This flag will be set to true after content is imported and set to false by default when user creates template in repo manually. On upgrade all templates present in mgnl-inplacetemplates will be upgraded as long as they either do not exist or exist with autoImport set to true. This will allow imported templates to be enabled by default, but user can prevent them from being updated and keep them disabled if other version (e.g. from resources) should be used.
As for the folder location, in theory templates can be in mgnl-bootstrap and I can modify default bootstraping to check the "autoImport" value for templates, but it seems cleaner for now to have templates in special folder and handling only as part of ME module. Or we could make this general feature and allow people to stop upgrades of any particular nodes by setting autoImport=false. Opinions and suggestions are welcome.

Comment by Jan Haderka [ 10/Oct/08 ]

Added TemplatesBootstrapTask to bootstrap the templates from mgnl-bootstrap-templates. Templates will be updated only when do not exist in repo yet or when autoImport is set to true on the template in repo.

Comment by Philipp Bracher [ 10/Oct/08 ]

The current tasks seams to be to restrictive to me. We have our templates in the jar (for instance /baukasten) and as long you don't customize a template it is served from the jar. In short the path in the jar and in the repository must be the same and therefore can't be /mgnl-bootstrap-templates.

Perhaps you just generalize the task and add a specific instance to the baukasten version handler.

Comment by Jan Haderka [ 10/Oct/08 ]

So you want anything that is named templates.x.y.z.xml to be imported? That seems way too open to me, you can get lots of unwanted content imported in the repo that way.
.

Comment by Jan Haderka [ 10/Oct/08 ]

On second thought the task is probably not doing what you had in mind at all. What you actually want is to get any template and transform it in template in the repo, rather then simply bootstrap previously exported templates from the repo, correct?

Comment by Magnolia International [ 10/Oct/08 ]

Some comments :

  • do new IsInstallSamplesTask(String, String, new TemplatesBootstrapTask())); in baukasten module
  • folders should be imported as folders (if a template as the same name, i'm ok with some ugly exception, but same name siblings being allowed, i don't see why that would be a problem?)
  • if you look at the demo, there are two nodes "info" / "magnolia" / etc... of type template - strange no ?
  • TemplatesBootstrapTask should be called something like TemplateImportTask, it does not bootstrap.
  • the task should take some sort of parameter (a path, a mask, whatever we already have that will make it simple to read) instead of blindly importing each and every template it finds
Comment by Jan Haderka [ 13/Oct/08 ]
  • From what I understood templates should be extracted into repo always not only when samples are installed.
  • folders are now imported as folders
  • changed task to allow using regex to limit what templates will be imported. Currently set to "/baukasten/.*\.ftl" for baukasten module.
  • renamed task to TemplatesInstallTask
Comment by Magnolia International [ 14/Oct/08 ]

Why use a regex when everywhere else we use a mechanism similar to ClasspathResourcesUtil.Filter ? Why is this task still extending BootstrapResourcesTask while it doesn't bootstrap anything and totally overrides its execute method ?

Comment by Jan Haderka [ 14/Oct/08 ]

regex - i guess this is a matter of the taste. I find it easier to read then implementing the filter to achieve the same. Is there any other reason to use the filter except for the fact that it is used elsewhere?
extension - it still uses getResourcesToBootstrap() method from BootstrapResourcesTask.

Comment by Magnolia International [ 14/Oct/08 ]

regex - consistency > taste.

subclassing: ... and then completely overrides the acceptResource method. All it does is a call to ClasspathResourcesUtil.findResources() which does not imo justify a misleading subclassing.

Comment by Jan Haderka [ 14/Oct/08 ]

Changed parrent class to AbstractTask.
The ContentResourceUtil.Filter is used to filter out the resources and was used from the beginning. There is no case I could see where we pass instance of the filter directly to the task while creating new instance. Instead in all the cases we construct the filter in the tasks themselves.

Generated at Mon Feb 12 05:57:32 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.