shorter templating attributes prefix #22

line-o · 2023-02-06T20:22:31Z

Your Ideal Solution

At the moment the attributes used to declare functions, variables and other options are prefixed with data-template. This serves two purposes:

because they are all data-attributes, the templates themselves are valid HTML5 documents (or document fragments for includes)
data-template may be verbose but makes it also pretty clear that this specific attribute has to do with templating

Now if we look at a simple template this leads to quite a lot of templating related markup in comparison to the actual contents.

<html>
    <head>
        <title>${title}</title>
        <script data-template="templates:include"
            data-template-path="${includes?scripts}"></script>
        <style data-template="templates:include"
            data-template-path="${includes?styles}"></style>
    </head>
    <body>
        <!-- include template from module -->
        <nav data-template="templates:include"
            data-template-path="${includes?menubar}"></nav>
        <main data-template="templates:include"
            data-template-path="${includes?main}"></main>
    </body>
</html>

In order to shorten the prefix we could choose to sacrifice one or two of the above principles by choosing a shorter prefix:

data-tpl
data-t
tpl

The last option would yield:

<html>
    <head>
        <title>${title}</title>
        <script tpl="templates:include"
            tpl-path="${includes?scripts}"></script>
        <style tpl="templates:include"
            tpl-path="${includes?styles}"></style>
    </head>
    <body>
        <!-- include template from module -->
        <nav tpl="templates:include"
            tpl-path="${includes?menubar}"></nav>
        <main tpl="templates:include"
            tpl-path="${includes?main}"></main>
    </body>
</html>

Template attributes that are not yet prefixed like data-target and data-start, data-end should be prefixed as well. And the attribute declaring the template function to use should include a keyword indicating that. function, handler, f, fun, func are options.

Any Alternative Options

Even shorter prefix with just t is possible. Shorter built-in function names can further reduce the clutter.

<main t-func="t:include" t-path="${includes?main}">

There is also the possibility to declare a namespace that is bound to the templating name. But I can foresee this would create a lot of problems down the line.

<main t:func="t:include" t:path="${includes?main}">

Additional Context

This is part of the effort to release the next major version #17

The text was updated successfully, but these errors were encountered:

lguariento · 2023-02-07T13:00:23Z

I've never found the data-template to be unnecessarily verbose, although I see your point here.

That said, if we're going to do it let's do it properly then: I'd go for the shortest version t.

<main t-func="t:include" t-path="${includes?main}">

adamretter · 2023-02-07T14:33:17Z

I would imagine that we need to stay with the data- prefix to maintain compatibility with HTML5.

joewiz · 2023-02-07T14:45:11Z

The current state does not bother me in the least. The advantages @line-o describes at the top - compatibility with HTML5 and semantic clarity of the name - are important and worth preserving.

line-o · 2023-02-08T21:11:27Z

OK, I hear you. Thanks for the feedback. So any shortening will only be something that one might be allowed
to configure for themselves.

line-o · 2023-02-08T21:13:18Z

About the HTML5 compatibility. This will really only affect documents where the template attributes have not
been filtered out. I would like to make the filtering of template attributes the new default.
Is there anything speaking against this?

joewiz · 2023-02-08T21:17:58Z

In my applications, at least, templating attributes are solely used for server-side processing and do not need to be sent to the client.

line-o · 2023-02-08T21:38:04Z

This feature will not be included in the next major version but can be part of a later release.

yamahito · 2023-02-10T14:19:02Z

It seems to me that there are two cases:

The attributes are preserved in the HTML, and should therefore use the data- prefix. I have seen instances where these have been used for both @data-template and @data-template-arg for either CSS styling (which I think is a bit of laziness, and hard to excuse), or for front-end javascript responsive design (where I think there is a more compelling use case).
The attributes are filtered out and not preserved in the HTML, just in the XML template files. In these cases, I am struggling to see why we are not considering namespaces to do the prefixing job.

line-o · 2023-02-10T19:37:24Z

@yamahito yes,

I agree. If those attributes are preserved, for some other reason than debugging, then they have to be data-attributes. I would never do it myself, for separation of concerns, but that might be a theoretical point of view.
OK, so if you say there should be no problem I am more confident we can go down that route :)

Can we make namespaces configurable as we can with prefixed attribute-names?

line-o · 2023-02-10T19:41:29Z

I am in the team that uses JS-specific CSS-classes.

yamahito · 2023-02-13T14:31:51Z

Can we make namespaces configurable as we can with prefixed attribute-names?

I'm not 100% clear on what you mean here by "configurable"?

line-o · 2023-02-15T10:23:13Z

As I understood the feedback, some want to keep template specific attributes as data-attributes.
In order to keep this as it is but also allow to configure other strategies one would have to provide
a configuration option to templates:render

The start and end delimiters are changed so that the templates can be inserted directly.

To continue using "data-template"

templates:render(
    <html>
        <body data-template="templates:if-parameter-set" data-template-param="data">[[data]]</body>
    </html>,
    map { "data": "oversimplified example" },
    map {
        $templates:CONFIG_ATTRIBUTE_PREFIX : "data-template",
        $templates:CONFIG_START_DELIMITER: '\[\[',
        $templates:CONFIG_END_DELIMITER: '\]\]'
    }
)

To use `t` as a prefix

templates:render(
    <html>
        <body t="templates:if-parameter-set" t-param="data">[[data]]</body>
    </html>,
    map { "data": "oversimplified example" },
    map {
        $templates:CONFIG_ATTRIBUTE_PREFIX : "t",
        $templates:CONFIG_START_DELIMITER: '\[\[',
        $templates:CONFIG_END_DELIMITER: '\]\]'
    }
)

To use `htpl` as a namespace (possible?)

Also notice how we cannot have and empty prefix as that would render the node handling function declaration impossible as long as it is just using the prefix as its attribute name.

Also parameters named "param" or "parameter" create additional problems when trying to distinguish them from
the proposed approach in #23 (both old and new approaches cannot coexist).

templates:render(
    <html xmlns:htpl="http://exist-db.org/xquery/html-templating">
        <body htpl:x="templates:if-parameter-set" htpl:x-param="data">[[data]]</body>
    </html>,
    map { "data": "oversimplified example" },
    map {
        $templates:CONFIG_ATTRIBUTE_NS : "http://exist-db.org/xquery/html-templating",
        $templates:CONFIG_ATTRIBUTE_PREFIX : "x",
        $templates:CONFIG_START_DELIMITER: '\[\[',
        $templates:CONFIG_END_DELIMITER: '\]\]'
    }
)

line-o · 2023-02-15T10:29:23Z

@yamahito Thinking about it having all templating related attributes in a separate, known namespace would make checks and filtering easier.

But you could definitely only have one strategy per rendering, either with or without namespaces attributes.

line-o added the enhancement New feature or request label Feb 6, 2023

line-o mentioned this issue Feb 6, 2023

Next major version #17

Open

5 tasks

line-o mentioned this issue Feb 10, 2023

unify all templating attributes to have the same prefix #23

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

shorter templating attributes prefix #22

shorter templating attributes prefix #22

line-o commented Feb 6, 2023 •

edited

Loading

lguariento commented Feb 7, 2023

adamretter commented Feb 7, 2023

joewiz commented Feb 7, 2023

line-o commented Feb 8, 2023

line-o commented Feb 8, 2023

joewiz commented Feb 8, 2023

line-o commented Feb 8, 2023

yamahito commented Feb 10, 2023

line-o commented Feb 10, 2023 •

edited

Loading

line-o commented Feb 10, 2023

yamahito commented Feb 13, 2023

line-o commented Feb 15, 2023 •

edited

Loading

line-o commented Feb 15, 2023

shorter templating attributes prefix #22

shorter templating attributes prefix #22

Comments

line-o commented Feb 6, 2023 • edited Loading

Your Ideal Solution

Any Alternative Options

Additional Context

lguariento commented Feb 7, 2023

adamretter commented Feb 7, 2023

joewiz commented Feb 7, 2023

line-o commented Feb 8, 2023

line-o commented Feb 8, 2023

joewiz commented Feb 8, 2023

line-o commented Feb 8, 2023

yamahito commented Feb 10, 2023

line-o commented Feb 10, 2023 • edited Loading

line-o commented Feb 10, 2023

yamahito commented Feb 13, 2023

line-o commented Feb 15, 2023 • edited Loading

To continue using "data-template"

To use t as a prefix

To use htpl as a namespace (possible?)

line-o commented Feb 15, 2023

line-o commented Feb 6, 2023 •

edited

Loading

line-o commented Feb 10, 2023 •

edited

Loading

line-o commented Feb 15, 2023 •

edited

Loading

To use `t` as a prefix

To use `htpl` as a namespace (possible?)