I recently ran into some behavior I wasn't expecting: I accidentally had a extra {{end}} statement in my template. The result was that parsing stopped at that point. In effect, it acted as if it were the end of the template.
I looked in the documentation for this -- and perhaps a way to enforce strict matching of 'end to a block begin' -- but couldn't find anything. When thinking about how this script-ending end statement may be used, it is logically problematic, as it can only be used when not inside another block. In other words, it can only be used at the outermost level.
In order to prevent possible template bugs created by users (which was my situation), I would like to introduce a new ParserOption called EnforceEndStatementMustMatchBlockBegin. The setting would default to false, thus ensuring that existing functionality is backwards compatible. When setting this to true, if an end statement is found during parsing, and the _blockLevel is 1, an error will be logged.
The reason I went with a ParserOption vs. an option on the TemplateContext, is because the parser already logs an error if an end statement is not found for a block. This setting just triggers the parser to enforce a match in the other direction.
I am attaching a pull request -- documented code with unit tests -- to aid in this request. I'm open to suggestions for changes as well. Thanks.
I recently ran into some behavior I wasn't expecting: I accidentally had a extra {{end}} statement in my template. The result was that parsing stopped at that point. In effect, it acted as if it were the end of the template.
I looked in the documentation for this -- and perhaps a way to enforce strict matching of 'end to a block begin' -- but couldn't find anything. When thinking about how this script-ending end statement may be used, it is logically problematic, as it can only be used when not inside another block. In other words, it can only be used at the outermost level.
In order to prevent possible template bugs created by users (which was my situation), I would like to introduce a new ParserOption called EnforceEndStatementMustMatchBlockBegin. The setting would default to false, thus ensuring that existing functionality is backwards compatible. When setting this to true, if an end statement is found during parsing, and the _blockLevel is 1, an error will be logged.
The reason I went with a ParserOption vs. an option on the TemplateContext, is because the parser already logs an error if an end statement is not found for a block. This setting just triggers the parser to enforce a match in the other direction.
I am attaching a pull request -- documented code with unit tests -- to aid in this request. I'm open to suggestions for changes as well. Thanks.