[MGNLRES-210] Groovy as resources: Allow groovy in light modules as model classes Created: 08/Sep/15 Updated: 29/Mar/22 Resolved: 01/Mar/22 |
|
| Status: | Closed |
| Project: | Magnolia Resources Module |
| Component/s: | resourceLoaders |
| Affects Version/s: | 2.4.1 |
| Fix Version/s: | None |
| Type: | Story | Priority: | Neutral |
| Reporter: | Christian Ringele | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 8 |
| Labels: | devwl, pm | ||
| Remaining Estimate: | 0d | ||
| Time Spent: | 0.5d | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||
| Template: |
|
||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||||||
| Release notes required: |
Yes
|
||||||||||||||||||||
| Documentation update required: |
Yes
|
||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||
| Story Points: | 13 | ||||||||||||||||||||
| Team: | |||||||||||||||||||||
| Description |
|
The new resource loading mechanism provides a lot of templating possibilities for light modules. The need for a model class is not the same Java scope as "real" back-end adaptions. We have a groovy implementation, but: Suggestion: modelClass: travel-demo.templates.components.LinkModel What we gain: |
| Comments |
| Comment by Philipp Bärfuss [ 10/Dec/15 ] |
|
It is not ultimately important that the files are loaded by the new resources API. It might be enough to make groovy files loadable for a the resources root path with its own mechanisms. |
| Comment by Michael Mühlebach [ 17/Dec/15 ] |
|
This would actually be a good first step to migrate the groovy script to the new loading cascade. The issue is less the new API and more loading it from !JCR and the migration would reduce some of the uncertainty in this area. |
| Comment by Federico Grilli [ 29/Jan/16 ] |
|
As I already tackled other Groovy issues which should eventually culminate in the ability to use Groovy files on the file system for light development, I gave this a try at https://git.magnolia-cms.com/projects/MODULES/repos/groovy/commits/93843e899da6f39158631fcbaca810b5f4fc3ab7 One problem I stumbled across is how to specify and resolve e.g. modelClasses in yaml files. So far, in JCR config we refer to Groovy scripts as normal Java classes, e.g. foo.bar.MyGroovyClass, that is by their fully-qualified class names. So here are some questions (and some possible answers): Q1) How do we enforce devs to declare a valid package in their file system scripts? Q2) FS scripts are resolved relative to the magnolia.resources.dir. Say you have a module there called hello-magnolia and your script is under /hello-magnolia/scripts/MyModel.groovy. In order to be resolved correctly that script should declare a package hello-magnolia.scripts. However the hyphen sign - is not valid in a Java class package name and compilation would eventually fail. How can we solve this? UPDATE
|
| Comment by Christopher Zimmermann [ 03/Feb/16 ] |
|
From PM perspective, we can document that groovy loading from file system is only available if the module name has no hyphens. Accordingly we will change our samples/documentation/tutorials to use a convention without hyphens. It becomes the new convention. |
| Comment by Christopher Zimmermann [ 03/Feb/16 ] |
|
From PM perspective, OK if we are not using the resources API as it appears that the functionality for the end user will be very good. For example if they change the script - those changes will be reflected when pages render (also when the definition which uses it changes) without having to restart the server. |
| Comment by Christopher Zimmermann [ 03/Feb/16 ] |
|
Removed the 13 story point estimation, as Federico has a working POC with unit tests and feels it will be less work - from 3 to 5 story points. |
| Comment by Federico Grilli [ 18/Feb/16 ] |
|
Story points take into account what was decided after the second arch meeting on the subject and which is summarised at https://jira.magnolia-cms.com/browse/DEV-124 (see comment section) |
| Comment by Christopher Zimmermann [ 13/Apr/16 ] |
|
Please include me in review. |
| Comment by Michael Mühlebach [ 06/Jun/16 ] |
|
btw: I found a good article to solve the one security issue: http://mrhaki.blogspot.ch/2014/04/groovy-goodness-restricting-script.html I saw as well in the ScriptEngine API that we can have a custom class loader configuration to white and blacklist packages and even have a custom class loader itself. |
| Comment by Christopher Zimmermann [ 19/Jan/17 ] |
|
Removed from Backlog because of new JS Models module covering similar requirement. I still see this enhancement as desirable, but with a lower urgency. |