the current sightly script engine implementation provides some hooks for
extensibility:
- provide own script bindings via o.a.s.scripting.api.BindingsValuesProvider
- provide own runtime extensions vis
o.a.s.scripting.sightly.extension.RuntimeExtension
but it does not seem to support defining custom block statements (custom
data-sly-xxx functions). although the sightly implementation is nicely
modularized here and uses OSGi to define it's own plugins for block statements,
the Plugin interface [1] is in a private package.
is this intentional, or can we change it to support customizations here?
---
i understand that sightly was designed to overcome several problems in JSP, one
of it was the "taglib hell" with overuse of custom tags leading to quite
proprietary tag syntaxes difficult to understand and maintain. but still there
are some use cases where it would be useful to define own block statements
because using the use API needs too much boilerplate code.
example - consider a usecase for building a link from a set of resource
properties, and this involves more logic than just getting a path and adding
".html" to it, so business logic on the java is involved and a sling model to
access it. example markup (link.attributes returns a map):
<a data-sly-use.link="com.myapp.ResourceLink"
data-sly-attribute="${link.attributes}" data-sly-test="${link.valid}">
${properties.linkTitle}
</a>
using a custom sightly extension this would remove a lot of boilerplate code:
<a data-sly-resource-link>
${properties.linkTitle}
</a>
an alternative would be to use a slightly template, but this still requires
more code for calling and the specific inclusion and management of a sightly
template library file.
stefan
[1]
https://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/sightly/engine/src/main/java/org/apache/sling/scripting/sightly/impl/plugin/Plugin.java
