Don't attempt to relocate template links that contain MEXL interpolation.

Description

Check if a template reference contains a MEXL expression and if it doesn't don't attempt to relocate the reference when the template is being loaded.

If a template contains a MEXL expression in a reference, it will not be interpreted until after the template has been applied, and that's intended. For example a template image element might have this:

The current template relocation code does not not know about MEXL and attempts to relocate the src link. The link is invalid (the character ^ is not allowed in a URI reference), so a warning is generated.

Everything works out in the end because the MEXL is evaluated after template application, but it would be better to avoid relocation altogether for links containing MEXL expressions.

Environment

None

Activity

Show:
Garret Wilson
7 days ago
Edited

Currently the objective is to ignore pre-mesh "references" such as src="^{plan.reference(artifact, it.aspect('preview'))}" which are interpolations of the entire string, as they will be evaluated after template application during meshing.

However there is also the possibility of interpolation within the URI, such as foo/^{var}/bar/test.txt; in this case we might want to somehow ignore the interpolated pat and try to relocate the entire path and leave the interpolated parts to be evaluated later. But this would only work for some paths, and it would probably be difficult to tell up-front which were supported and which were invalid. We don't need that use case as the moment so we'll leave it be; this ticket will ignore any interpolations in template processing.

Nevertheless recognizing that interpolation of the entire value (as a query) is not exactly the same thing as interpolation within a URI indicates that perhaps a better approach would be to provide a separate mesh replacement attribute such as Thymeleaf does using th:src. This would sidestep the problem altogether, and interpolation within a reference at template time would continue to be an error because truly it can't be relocated.

The question is whether we want to take the step of introducing a parallel set of MEXL replacement attributes at this point, and deal with the details it will raise (e.g. whether to use a separate namespace, whether other target attribute namespaces would ever be supported, etc.).

Assignee

Garret Wilson

Reporter

Garret Wilson

Labels

None

Epic Link

Components

Fix versions

Priority

Minor