Add `data-sly-dataset` block statement to export data-* attributes to element scope

[adamcin]

Dataset

data-sly-dataset:

• Exports any preceding data- attributes defined on the element as a (String -> String) hash table akin to HTML5 dataset, but excludes data-sly- attributes. For subsequent data-sly-use attributes defined on the same element, the entries of the hash table would be merged with any options specified in the data-sly-use attribute.
• Element: always shown.
• Attribute value: optional; hint(s) for post-processor transformations of the dataset.
• Attribute identifier: optional; customised identifier name to access the variable within expressions in nested scopes. If the identifier is omitted, the hash table values will not be exported beyond the scope of the element start tag. Expressions within subsequent attributes on the same element would be able to access the hash table using the default dataset identifier.

The data-sly-dataset attribute would serve two functions.

Export Data Attributes as Use Options

First, it would take advantage of native HTML syntax to provide an alternative to expression options for providing narrowly-scoped input arguments to the Use API.

For example:

<div data-parent-path="${resource.path}"
        data-filter="solutions"
        data-link-target="_blank"
        data-sly-dataset
        data-sly-use.articles="QueryArticles"
></div>

Would be equivalent to:

<div data-sly-use.articles="${'QueryArticles' @ parentPath=resource.path, filter='solutions', linkTarget='_blank'}"
></div>

Provide a Post-Process Hook for Contextual Rewriting

Second, it would provide a much narrower hook for a transformation stage than would a full-output SAX transformer to perform link rewriting or other similar environment- or context-sensitive function on attributes that are also used, by convention, to pass such contextual data to client-side scripts.

For example, a component may need to provide its client-side script the URL to a search results page, but this URL needs to be rewritten according to Sling Mapping rules:

<div class="quick-results" data-search-page="/content/mysite/en/us/searchresults.html"></div>

A transformation pipeline can be configured to handle all start element SAX events, but this comes with a performance penalty on every page where this component appears and also introduces a config management challenge to keep the full list of every data attribute containing an href up to date.

Instead of using a SAX pipeline against the entire response, a more discrete transformation API can be defined that only deals with Map<String, String> as input and output, and that is triggered only after the data-sly-dataset attribute is evaluated on an element.

<div class="quick-results" data-search-page="/content/mysite/us/en/searchresults.html" data-sly-dataset></div>

Could then be transformed to:

<div class="quick-results" data-search-page="/us/en/searchresults"></div>

I imagine there would be a couple constraints

1. Expression option values, which are typed, would take precedence over data attribute values, which would be coerced to string before being exported or rendered.
2. Post-process transformations would need to occur only at the point when the data- attributed is rendered. HTL expressions should only be evaluated using the pre-transformation values.

[raducotescu]

@adamcin, I fail to see the benefits of your proposal for the following reasons:

1. for the "Export Data Attributes as Use Options" use-case, this change might affect current implementations, if the data-* attributes correspond to global script variables, by overriding them in the Use object's arguments' map;

2. the "Contextual Rewriting" feature, as defined here, could be better implemented through a custom-fitted use-object rather than through language specification changes, because such configuration specific value output would be made more clear to developers, rather than performing the rewrite through post-processing pipelines.