Currently, loops are detected by calling resolver with the placeholder and then checking the return value.
This is both neither really clean, since the parsing and the compilation step are not seperated, nor is it really efficient, since the resolving could take a lot of time.
A system should be implemented which allows the parser to detect loops without depending on a resolver.
Two ways have been proposed by now:
* Mark loop placeholders with a certain sign (e.g. a # in front of the token)
Advantages: Keyword agnostic, can be incorporated very easily
Disadvantages: Not backwards compatible, would need to teach new users about this
(One could alleviate this by introducing an additional step which goes through it, resolves the document, and rewrites the loop constructs which is run every time a new template is submitted)
* Add the option to supply the parser with a set of keywords which mark loops
Advantages: Backwards compatible with old templates
Disadvantages: Introduce a new dependency for the parser
Currently, loops are detected by calling resolver with the placeholder and then checking the return value.
This is both neither really clean, since the parsing and the compilation step are not seperated, nor is it really efficient, since the resolving could take a lot of time.
A system should be implemented which allows the parser to detect loops without depending on a resolver.
Two ways have been proposed by now:
* Mark loop placeholders with a certain sign (e.g. a
#in front of the token)Advantages: Keyword agnostic, can be incorporated very easily
Disadvantages: Not backwards compatible, would need to teach new users about this
(One could alleviate this by introducing an additional step which goes through it, resolves the document, and rewrites the loop constructs which is run every time a new template is submitted)
* Add the option to supply the parser with a set of keywords which mark loops
Advantages: Backwards compatible with old templates
Disadvantages: Introduce a new dependency for the parser