Having worked with Sightly on a real project I can say I *do* have an opinion. The lack of extension points is a real problem with Sightly, because there's always some contingency that we can't think of ahead of time. When working with Sightly, the team ended up having to create a bunch of duplicate or crufty code to work around what is out of the box in JSP.
I would suggest making the plugin interface public and creating good documentation on how to correctly extend Sighty and to create some Sling-specific extensions similar to my recent contributions to the Sling JSP TagLib. I can't see any good reason to write a Sling Model to do something as simple as iterating through child resources or retrieving a resource at a known path. Regards, Dan On Wed, Jan 6, 2016 at 7:45 AM, Oliver Lietz <[email protected]> wrote: > On Monday 21 December 2015 18:01:40 Stefan Seifert wrote: > > 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? > > AFAIK it is intentional [and I have no strong opinion if it should be > opened > up for customizations or not (yet)]. > > > --- > > > > 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. > > This can easily be done with a custom tag processor in Thymeleaf also, see > Sling Dialect and Sling Include for example: > > > https://github.com/apache/sling/blob/trunk/contrib/scripting/thymeleaf/src/main/java/org/apache/sling/scripting/thymeleaf/internal/dialect/SlingDialect.java > > > https://github.com/apache/sling/blob/trunk/contrib/scripting/thymeleaf/src/main/java/org/apache/sling/scripting/thymeleaf/internal/processor/SlingIncludeAttributeTagProcessor.java > > Thymeleaf allows you to plug in your own template resolvers, message > resolvers > (i18n), dialects and cache manager. This is realized in Sling Scripting > Thymeleaf with OSGi Services[2]. So you can provide your custom dialect and > tag processors (with a custom namespace, e.g. data-wcmio-*) at runtime to > extend Thymeleaf. > > Regards, > O. > > [2] > > https://github.com/apache/sling/blob/trunk/contrib/scripting/thymeleaf/src/main/java/org/apache/sling/scripting/thymeleaf/internal/ThymeleafScriptEngineFactory.java > > > stefan > > > > [1] > > > https://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/sightly/engi > > > ne/src/main/java/org/apache/sling/scripting/sightly/impl/plugin/Plugin.java > >
