Hi,

Currently microsling looks for scripts under /sling/scripts, which is
not very convenient if running several apps in the same repository:
all scripts would end up under this path, which makes it harder to
package applications.

Here's a proposal for a different way of resolving scripts, with three
possible cases:

a) Node has a valid sling:resourceType property
The resource type is the value of this property, which, to be valid,
must not be empty and must start with a /.

The resource type is used as the base path under which to look for scripts.

For example, if sling:resourceType = /apps/blog/comment, microsling
looks for scripts named /apps/blog/comment/<method>.<ext>, where
<method> is the HTTP method (or the extension for the GET method, as
done now) and <ext> is a valid script extension according to the
available ScriptEngines.

b) Node doesn't have a valid sling:resourceType property
In this case, the resource type is the node type, for example "nt:unstructured".

To map to a script, the resource type is converted to a valid path,
and prefixed with "/apps/sling".

For an nt:unstructured node, microsling looks for scripts named
/apps/sling/nt/unstructured/<method>.<ext>

c) Script not found using either a) or b) rules
As a catch-all default (useful mostly for tutorials and simple example
apps), microsling looks for scripts named
/apps/sling/default/<method>.<ext>

WDYT?

-Bertrand

Reply via email to