Hi, I tend to agree with Vlad here. Sightly is just a templating language. The fact that we call it a scripting engine in Sling is mostly due to its Use-API, which was designed to allow to clearly separate the business logic from the view.
While we do have some extensions in Sling that are not defined by the spec (e.g. check the multitude of "objects" one can load with data-sly-use), these do not affect how things are rendered, nor do they enhance the language. The RuntimeExtensions that Stefan pointed to are merely plugin helpers - IMO they're processing filters, but again they don't affect the rendering. Stefan's example seems to be a really particular use-case, where a resource can describe a link. If we find the need for such a construct (e.g. data-sly-link) I think we need to make it as generic as possible (e.g. use a Map, not a Resource). If you look at the Sightly specification you'll notice that it tries to stay away from Sling's specifics (with the notable exception of selectors and suffixes). However I'd be more tempted to suggest the use of a template, or even a template library, for such cases. Regards, Radu On Wed, 6 Jan 2016 at 15:37 Vlad Bailescu <[email protected]> wrote: > 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 > > > > > > > > >
