[TASK] Consistent parser error handling for inline ViewHelpers #1102
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current
TemplateParserhas separate code paths for theinline 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:
The
ViewHelperResolverhas the option to ignore certainViewHelper 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:
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-basedViewHelpers is wrapped in a
try … catchblock, this wasn'tthe 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
@todoannotation has been added.