1 回答
TA贡献1834条经验 获得超8个赞
这是一个双重问题:第一个可能是在getInlineParams
函数中简化逻辑的方法,这对于这些简单的情况可能没有问题,但对于更复杂的情况可能会很糟糕。
第二个问题是完全无视类型。
{'{test}': coolFunctionWhichReturnsString('testParameter')}
被解析为(读作“字符串值”-“令牌类型”):
{
- 阻止开始{test}
- 一个字符串:
- 标点符号coolFunctionWhichReturnsString
- 一个名字(
-(不确定是哪种类型)testParameter
- 一个字符串)
- (再次)}
- 块结束
当您嵌套多个 {} 时,第一个问题将展开。第二个问题是由于一个简单的事实:
该类型很重要。
词法分析器有一项非常重要的任务,它删除用户可能选择表达字符串、注释的所有不同变体,它删除不相关的空格(因为它只是杂乱无章)等等。现在,如果你把每个Token
(有一个值和一个类型)当作只是一个包含你想要的字符串的奇怪对象,你就会遇到问题 - 很明显。
因此,如果要重新创建类似于原始输入的内容,则必须查看类型并在类型为字符串时添加引号。(文本可能是块之外的所有东西)
(这将是您所述问题的快速“解决方案”)
但是,从长远来看,忽略标记的语义会导致问题……因为您还必须以某种方式处理“coolFunctionWhichReturnsString”,即,您必须将其转换为某个函数调用。从理论上讲,您应该真正构建一个 AST 并在某个时候将其编译成适当的形式......
树枝解析器使用一种方法subparse
来解析内容,直到出现某个“结束”。(建立 AST,因为结构在某些时候也很重要)
更新:事实证明,在树枝文档中有一个用于编写节点解析器的页面,如果您遵循https://twig.symfony.com/doc/2.x/advanced.html,它可能会简化很多#registering-a-new-tag(信息从略高于“注册新标签”开始,非常简化了值的解析和使用)
- 1 回答
- 0 关注
- 204 浏览
添加回答
举报