Hi, I believe the whole beauty of Sightly (as a templating language) is that it has a concise HTML-based syntax. It provides the necessary flow control but restricts building too much logic into it, after all it's just a way to generate a view and all scripting/business logic should be kept in the Use objects. This will ensure a smooth transition between multiple projects that use Sightly. Anything that's needed for the view can be easily provided with good design of Use objects and helpers/utils.
I see any missing data-sly-** that's causing a lot of duplicate/boilerplate code as a chance to propose enhancements to the Sightly specification [3] instead of building a multitude of Sightly flavors through custom extensions. Best, Vlad [3] - https://github.com/Adobe-Marketing-Cloud/sightly-spec/blob/master/SPECIFICATION.md On Wed, Jan 6, 2016 at 3:40 PM, Daniel Klco <[email protected]> wrote: > 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 > > > > >
