templates - Scala/Lift - 试图理解 Lift 同时声称使用有效的 html 和倾向性提升 : tags and tag rewriting in render

Question

所有七件事 ( http://seventhings.liftweb.net/ ) 当然都很好，但我特别热衷于模板 ( http://seventhings.liftweb.net/templates ) 中的“Lift 支持设计者友好模板”的声明。

作为我学习 Lift 做事方式的步骤之一，我试图创建一个简单的对象创建形式:获取一些参数，将它们用作构造函数参数，然后将对象收起。经过一些研究和实验，我有两个问题:

似乎有相当大的倾向显着重写/修饰代码片段中的模板标记。

表单似乎没有使用有效或可识别的 html 元素。

我的依据是:

表单示例/文档似乎都是关于特殊提升:标签。 Exploring Lift 建议表单应如下所示:( http://exploring.liftweb.net/master/index-6.html )

<lift:Ledger.add form="POST">
  <entry:description />
  <entry:amount /><br />
  <entry:submit />
</lift:Ledger.add>

我不确定这是否是有效的 html5，虽然它可能是有效的 xhtml，但对于我们的设计师 friend 来说，这并不符合让您的模板看起来像真正的 html 的精神。我在别处读到(再也找不到了)我们确实可以选择使用实际的输入标签，但是我们不会得到 Lift 的奇特形式的某些部分连线之类的，段落不是很清楚关于我到底会错过什么，并且这些示例似乎对我编写一个普通的 html 表单并制作一个普通的 html 帖子不感兴趣。

demo.liftweb.net 示例 (1) 的代码表明您的模板应如下所示 (2)

<lift:surround with="default" at="content">
  <div class="lift:PersonScreen"></div>
</lift:surround>

PersonScreen 片段的代码也不完全有启发性，要么 (3)。还有其他几个模板示例，例如只有在特定位置的 ul 标签，才生成一系列复杂的 li，在代码段中包含嵌套元素。当然，您可以在 Scala 中使用 xml 并且它的可读性还不错，但是它仍然到处都是您的标记。这似乎违反了“设计师友好模板”的精神。

我想了解什么。

长期以来，我在 webapp 开发中严格遵循两条规则:

“代码”中没有标记( Controller 、业务模型)。

模板中没有任何业务逻辑。

Idiomatic Lift 似乎完全放弃了第一条规则，完全忽略了第二条规则的值(value)。这些规则对我很有帮助，我还没有准备好跟随似乎违反它们的例子而不理解为什么它不会造成困惑。我想了解为什么在 Lift 中可以在 Snippets 中生成如此多的显示代码。我还想了解为什么模板中的标记很少反射(reflect)输出是可以的。

我(认为我)想要的:

我希望我的所有标记都在我的模板中，并且几乎没有异常(exception)。我希望我的片段进行最少的模板修改，通常只替换“叶”标签上的元素文本并可能调整属性值。我想我已经为一个相当复杂的显示示例做了这个，我怀疑我可以使用相同的技术来生成一个普通的 html 表单，然后自己处理参数。如果我希望我的模板看起来像最终结果表单，我需要这样做吗？

回应和任何其他想法，特别是关于理解关于这些东西的 Lift 心态，将不胜感激。

谢谢!

http://demo.liftweb.net/simple_screen?F674431078927QJVVYD=_

https://github.com/lift/examples/blob/master/combo/example/src/main/webapp/simple_screen.html

https://github.com/lift/examples/blob/master/combo/example/src/main/scala/net/liftweb/example/snippet/Wizard.scala#L94

编辑

回应@OXMO456。 (感谢您的回复。)

我有，他们似乎只是证实了我的担忧:例如我们开始:

Lift templates contain no executable code. They are pure, raw, valid HTML.

这太棒了。后来:

The latter two mechanisms for invoking snippets will not result in valid Html5 templates.

然而，似乎每个人都在使用这两种机制中的第一种。此外，它说:

Third, the designers don’t have to worry about learning to program anything in order to design HTML pages because the program execution is abstracted away from the HTML rather than embedded in the HTML.

但是，我在 OP 中引用的示例片段非常一致地完全以编程方式生成标记。这似乎与以下目标背道而驰:(a) 拥有设计人员友好的模板，因此设计人员不必为 Freemarker 标记而烦恼，以及 (b) 将显示逻辑与业务逻辑分开。

第二个链接很有帮助和启发性，但它清楚地表明这不是 The Lift Way。然而，Lift Way 似乎也将大量的标记生成拖入片段中，这是(我认为)标记和业务逻辑的巨大复合。那是电梯方式吗？

Answer 1

这些是旧式标签，而不是设计人员友好的标签。

<lift:MySnippet>
  <b:field />
</lift:MySnippet>

变成

<div class="lift:MySnippet">
  <div class="field"></div>
</div>

旧式 Lift 模板是有效的 XML，而不是 XHTML - 所以你不能有未封闭的标签或任何东西 - 这将 Lift 与大多数框架区分开来，大多数框架将模板视为原始字符串，代码位贯穿始终，不考虑标签或结构。

顺便说一句，在旧式标签中，这些字段都是捏造的 - 它们不是某些标准 Lift 标签集的一部分。我可以很容易地做到:

<lift:MySnippet>
  <frobnicate:blorb />
</lift:MySnippet>

只要我的片段代码正在寻找该特定标签。

Lift 不允许您的模板中有任何逻辑。所有逻辑都发生在您的 Snippet 类中。所以对于上面的设计者友好的例子，我可能有一个这样的片段类:

 class MySnippet { 
   def render(in: NodeSeq): NodeSeq = ".field" #> Text("some text here")
 }

这将产生这个结果:

 <div>
   <div class="field">some text here</div>
 </div>

不可能在 Lift 模板中放入任何逻辑——它们所能做的就是调用 Lift 片段，这是所有工作发生的常规 Scala 类。

Lift 放弃了在实际代码中不应有任何显示逻辑的规则。为什么？因为它可以生成更多可重用的代码，因为 Scala 在语言中具有强大的 XML 支持，并且因为您的所有逻辑现在都被视为普通的旧 Scala 代码。

如果我定义了一个名为 CurrentTime 的 Lift 代码段，我可以简单地将它放入任何模板中，它会显示当前时间 - 对于老式 MVC 框架，每个操作方法都需要将时间设置为页面变量，然后需要修改我的模板以将其打印出来.对于更复杂的逻辑，老式框架可能需要模板中的条件。 Lift 不允许 - 您的所有逻辑都是常规的 Scala 代码，符合重构条件，易于测试，并与现代 IDE 兼容。