Method support via scripts

[krystian-panek-wttech]

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

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

[krystian-panek-wttech]

@tomasz-niedzwiedz-wttech WDYT?

[tomasz-niedzwiedz-wttech]

@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-wttech]

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-wttech]

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.