templates in separate workspace (freemarker)
(MGNLINTEMPL-1)
|
|
| 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. |
| 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 :
|
| Comment by Jan Haderka [ 13/Oct/08 ] |
|
| 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? |
| 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. |