DEV-124 - Getting issue details... STATUS
Rationale
After a first PoC done using custom code and a subsequent architecture meeting it was deliberated to use the Resources API instead. This concept aims at investigating some of the questions raised during that first meeting.
First meeting decisions
- Use Resources API
- Split scripts vs. classes (scripts stay in current workspace and functionality for executing scripts stay in groovy module. Support for classes will be removed from Groovy module and placed in resources workspace)
- Maintain support for scripts in JCR > scripts
Open questions
A new PoC using the Resources API has been crafted In order to quickly verify some assumptions. See https://git.magnolia-cms.com/projects/MODULES/repos/groovy/compare/commits?sourceBranch=refs%2Fheads%2Fpoc%2Fload-groovy-resources-api
Maintain additional classpath fallback after the cascade? (such classes would not show in the Resources app, so how can someone edit them?
Apparently such classes do appear in the Resources App. I created a Groovy script in a package classpath.scripts in Eclipse under src/main/resources
and the script is displayed in the app and can be hot fixed with no problem. The funny thing (but it may be due to the cp resource issues being tackled atm or to my borked IDE setup) is that it only shows up after the parent folder is manually created in the app.
Find a way to load classes via Resources API in deferred manner.
How/where to locate scripts in FS? (The packaging / structuring issue)
- module-names may contain dashes
- if module name is in the package name dash ( - ) needs to be replaced (by underscore? or use some other convention)
- next to the templates (convenient to edit, but hard to specify correct package name) vs. special folder (would make it easier to have package name w/o module name in it
- ideally would favor no special tricks
Overview
Content Tools