Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Method support via scripts #385

Open
krystian-panek-vmltech opened this issue Nov 24, 2022 · 5 comments
Open

Method support via scripts #385

krystian-panek-vmltech opened this issue Nov 24, 2022 · 5 comments

Comments

@krystian-panek-vmltech
Copy link

krystian-panek-vmltech commented Nov 24, 2022

as an addition to: #381

it may be hard to predict site content structure (exact tenant/lang/country node levels) so instead of assuming/hardcoding some conventions directly as ready to use APM methods, maybe it would better to give APM users ability to define functions only via scripts; I want to avoid enforcing users to implement own OSGi services to extend APM - that will probably never happen. But just implementing a JS script nearby APM script may bigger chance to happen IMO ;)

example

sites.apm.js

//var args, resolver // predefined (resolver from ootb engine support, see screenshot below) 
var sitePath = args['path'] // or named args (?)

var siteQuery = "SELECT * as s FROM nt:unstructured WHERE ISDESCENDANTNODE('" + sitePath + "')"
var siteIterator = resourceResolver.findResources(siteQuery)
// ... some processing
return sites // [['country': 'us', 'language': 'us', path' '/content/mysite/us/us'], ...]

all.apm

DEF sites = FUNC('sites', {path: '/content/mysite'}) // or sth similar

FOR-EACH sites // ... (as in PR)

*.apm.js should be handled by Javascript Sling script engine
image

https://sling.apache.org/documentation/bundles/scripting.html

@krystian-panek-vmltech
Copy link
Author

@tomasz-niedzwiedz-wttech WDYT?

@tomasz-niedzwiedz-wttech
Copy link

tomasz-niedzwiedz-wttech commented Nov 24, 2022

@krystian-panek-wttech I'd be very careful using JavaScript runtimes, as they may come with a significant performance overehad. Also, as far as I know, Nashorn is deprecated https://openjdk.org/jeps/335 and will be removed

Also, I wouldn't say implementing an OSGi service is something no one would do. It's very common to extend things in AEM this way. Reference providers, transformers, to name a couple off the top of my head. Running arbitrary scripts seems like a step too far, for security reasons as well. I'd be more comfortable with a well-designed, tested OSGi service that gets the full treatment of custom code.

@krystian-panek-vmltech
Copy link
Author

still using script may be easier for many APM users, I am very sure about it. and it will take many years on AEM that it will no longer support JS script engine. I believe there are cloud configs and other AEM features still using it and for backward compatibility they will need to extend support of that script engine.

@krystian-panek-vmltech
Copy link
Author

krystian-panek-vmltech commented Nov 24, 2022

These scripts may have unlimited use cases. And the ease of creating it may be the killer feature and that's why I recommend to do this in that way. Imagine dynamic lookup of paths dictionary which will returns paths according to aem version detected. Then it will be possible to implement aem version aware APM scripts

@tomasz-niedzwiedz-wttech

Personally, I wouldn't want such scripts to have unlimited capabilities. I'd like to be able to implement one thing, similar to a stored procedure, test it, deploy it and make it available. For unlimited capabilities, there's already the Groovy console, and I fear enabling something similar could lead to monstrosities being created, where a script is just supposed to assign ACLs to nodes.

I can see how the prospect could be exciting, but I don't think of this flexibility as a significant benefit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants