Skip to content

Conversation

@s2b
Copy link
Contributor

@s2b s2b commented Jun 5, 2025

The current TemplateParser has separate code paths for the
inline and the tag-based ViewHelper syntax. While the actual
rendering is consistent in the end, the handling of parsing
errors is quite different. This patch performs two related
changes to the parsing algorithm of inline ViewHelpers:

  1. Support Ignored ViewHelper Namespaces

The ViewHelperResolver has the option to ignore certain
ViewHelper namespaces, which leads to the parser ignoring
them completely and returning the uncompiled ViewHelper
code as-is. The original intent of this feature seems to be that
it should be possible to use XML namespaces within a Fluid
template, without the Fluid parser messing with the tags.

For inline ViewHelpers this never worked, which makes
kind of sense, since there is no overlapping syntax with
XML. However, this can lead to unexpected results if you
want to disable the parsing of certain ViewHelper
namespaces for other purposes: This will only work if
your template only uses tag-based variants of these
disabled ViewHelpers. Inline ViewHelpers will lead to
an exception.

With this patch, the behavior is more reasonable: If an
ignored ViewHelper namespace is used within a chain
of ViewHelper calls, the parsing of the whole chain is
skipped.

Example:

Ignore namespace "i":

{namespace i}

this already worked:

<i:foo />
<i:foo></i:foo>

this lead to an exception or just rendered the ViewHelper
anyways (!) if it's registered as valid global namespace:

{i:foo()}
  1. Usage of Fluid's ErrorHandler for Inline ViewHelpers

If the previous example lead to an exception, it was not possible to
limit the scope of that exception by using Fluid's
ErrorHandlerInterface. While the parsing code of tag-based
ViewHelpers is wrapped in a try … catch block, this wasn't
the case for the inline parsing block.

This patch adds the same possibility to influence the error
handling to the inline ViewHelpers as well.

Due to inconsistencies in parsing state, it is still not possible
to apply this to closing ViewHelper tags as well, but a @todo
annotation has been added.

@s2b s2b force-pushed the task/consistentViewHelperIgnore branch from b98bde8 to 0bd2d2c Compare June 5, 2025 15:15
The current `TemplateParser` has separate code paths for the
inline and the tag-based ViewHelper syntax. While the actual
rendering is consistent in the end, the handling of parsing
errors is quite different. This patch performs two related
changes to the parsing algorithm of inline ViewHelpers:

1. Support Ignored ViewHelper Namespaces

The `ViewHelperResolver` has the option to ignore certain
ViewHelper namespaces, which leads to the parser ignoring
them completely and returning the uncompiled ViewHelper
code as-is. The original intent of this feature seems to be that
it should be possible to use XML namespaces within a Fluid
template, without the Fluid parser messing with the tags.

For inline ViewHelpers this never worked, which makes
kind of sense, since there is no overlapping syntax with
XML. However, this can lead to unexpected results if you
want to disable the parsing of certain ViewHelper
namespaces for other purposes: This will only work if
your template only uses tag-based variants of these
disabled ViewHelpers. Inline ViewHelpers will lead to
an exception.

With this patch, the behavior is more reasonable: If an
ignored ViewHelper namespace is used within a chain
of ViewHelper calls, the parsing of the whole chain is
skipped.

Example:

```
Ignore namespace "i":

{namespace i}

this already worked:

<i:foo />
<i:foo></i:foo>

this lead to an exception or just rendered the ViewHelper
anyways (!) if it's registered as valid global namespace:

{i:foo()}
```

2. Usage of Fluid's ErrorHandler for Inline ViewHelpers

If the previous example lead to an exception, it was not possible to
limit the scope of that exception by using Fluid's
`ErrorHandlerInterface`. While the parsing code of tag-based
ViewHelpers is wrapped in a `try … catch` block, this wasn't
the case for the inline parsing block.

This patch adds the same possibility to influence the error
handling to the inline ViewHelpers as well.

Due to inconsistencies in parsing state, it is still not possible
to apply this to closing ViewHelper tags as well, but a `@todo`
annotation has been added.
@s2b s2b force-pushed the task/consistentViewHelperIgnore branch from 0bd2d2c to 037fcb0 Compare June 5, 2025 15:19
@s2b s2b added this to the Community Budget Q2/2025 milestone Jun 7, 2025
@s2b s2b merged commit 10a16f0 into main Jun 11, 2025
8 checks passed
@s2b s2b deleted the task/consistentViewHelperIgnore branch June 11, 2025 16:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants