[jira] [Comment Edited] (SLING-6967) Allow to throw exceptions in data-sly-resource for invalid paths

["Konrad Windszus (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16055389#comment-16055389 ] 

Konrad Windszus edited comment on SLING-6967 at 6/20/17 8:55 AM:
-----------------------------------------------------------------

An example would be to include a resource on a fix level from another resource (e.g. a logo component which is being maintained at {{/content/home/jcr:content/logo}} from {{/content/home/subpage}})

The HTL of the container script (i.e. the one for {{/content/home/subpage}} which includes the logo might look like this
{code}
<sly data-sly-use.page="my.own.Page"></sly>
<div data-sly-test="${page.homePageLogoPath}" data-sly-resource="${page.homePageLogoPath}"></div>
{code}

If the {{data-sly-test}} would not  be included, in case the {{my.own.Header#getHomePageLogoPath()}} would throw an exception, the data-sly-resource would still be executed, because the exception is being swallowed by the HTL EL and converted to the empty string! That might in the worst case lead to a cycle because the include is on the same resource again.

With the {{data-sly-test}} the div would not be rendered in case {{my.own.Header#getHomePageLogoPath()}} would return the empty string or throw an exception. In my case I would be interested to explicitly throw an exception, because the rendering of the page does not make sense in case this use-case occurs (i.e. a logo is not maintained). I cannot easily achieve that behaviour because I cannot explicitly throw an exception from within the HTL script (and therefore trigger a generic exception handler in a component servlet filter).


was (Author: kwin):
An example would be to include a resource on a fix level (e.g. a logo component which is being maintained at {{/content/home/jcr:content/logo}})

The HTL of the container script which includes the logo might look like this
{code}
<sly data-sly-use.header="my.own.Header"></sly>
<div data-sly-test="${header.homePageLogoPath}" data-sly-resource="${header.homePageLogoPath}"></div>
{code}

If the {{data-sly-test}} would not  be included, in case the {{my.own.Header#getHomePageLogoPath()}} would throw an exception, the data-sly-resource would still be executed, because the exception is being swallowed by the HTL EL and converted to the empty string! That might in the worst case lead to a cycle because the include is on the same resource again.

With the {{data-sly-test}} the div would not be rendered in case {{my.own.Header#getHomePageLogoPath()}} would return the empty string or throw an exception. In my case I would be interested to explicitly throw an exception, because the rendering of the page does not make sense in case this use-case occurs (i.e. a logo is not maintained). I cannot easily achieve that behaviour because I cannot explicitly throw an exception from within the HTL script (and therefore trigger a generic exception handler in a component servlet filter).

> Allow to throw exceptions in data-sly-resource for invalid paths
> ----------------------------------------------------------------
>
>                 Key: SLING-6967
>                 URL: https://issues.apache.org/jira/browse/SLING-6967
>             Project: Sling
>          Issue Type: Improvement
>          Components: Scripting
>    Affects Versions: Scripting HTL Engine 1.0.34
>            Reporter: Konrad Windszus
>
> If the path for {{data-sly-resource}} is dynamic you need to set it via expression language. If the underlying Java Pojo throws an exception while retrieving the path this exception is being caught by HTL EL and leads to the empty path (i.e. the behaviour is changed drastically because the wrong resource is being included)
> Since propagating the exception through the HTL EL is probably an incompatible change I would suggest to add an additional optional option like {{isInvalidPath}}. If that is set to {{true}} there should be a {{SightlyException}} thrown with an according error message that the given path is invalid.
> A concrete use case for that is a reference component, which would otherwise end up in a cycle because it would otherwise include itself.
> The only other workaround would be to use {{data-sly-test}} on the dynamically retrieved path, but it would not be possible to throw an exception here (and therefore break rendering of the whole HTL script).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)