七件事(http://seventhings.liftweb.net/)当然都不错，但是我对模板(http://seventhings.liftweb.net/templates)中的声明“Lift支持设计师友好的模板”特别感兴趣。
作为学习Lift的工作方式的第一步，我试图创建一个简单的对象创建表单:接受一些参数，将它们用作构造函数参数，然后将对象收起。经过一些研究和实验，我有两个问题:
我基于此:
表单示例/文档似乎都与特殊的lift:标签有关。探索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开发中一直严格遵循两个规则:
惯用升降机似乎完全放弃了第一条规则，而完全错过了第二条规则的值(value)。这些规则对我很有帮助，我还不准备跟随似乎违反它们的示例，而又不理解为什么它不会造成困惑。我想了解为什么在Lift中可以在代码段中生成大量显示代码的原因。我还想了解为什么模板中的标记很少反射(reflect)输出是可以的。
我(想想)想要的:
我希望所有带有很少(如果有的话)异常(exception)的标记都在我的模板中。我希望我的代码片段进行最少的模板处理，通常只替换“叶子”标签上的元素文本，并可能调整属性值。我认为我已经为一个相当复杂的显示示例完成了此操作，并且我怀疑我可以使用相同的技术来生成普通的html表单，然后自己处理这些参数。如果我希望模板看起来像最终结果表格，那是我需要做的吗？
回应和任何其他想法，特别是在理解有关此内容的Lift思维方式上，将受到极大的赞赏。
谢谢!
编辑
响应@ OXMO456。 (感谢您的回复。)
我有，他们似乎只是在确认我的疑虑:我们从开始:
太棒了然后再:
但是每个人似乎都使用这两种机制中的第一种。另外，它说:
但是，与我在OP中引用的示例代码片段一样，这些代码片段完全是通过编程方式完全生成标记的。这似乎与以下目标相反:(a)具有设计者友好的模板，因此设计者不必为Freemarker标记所困扰，以及(b)将显示逻辑与业务逻辑分离。
第二个链接很有帮助和指导意义，但很清楚这不是“提升方式”。但是，Lift Way似乎也将标记生成的全部负载拖到了摘要中，(我认为)标记和业务逻辑的巨大混合。那是电梯方式吗？
最佳答案
这些是旧式标签，而不是设计师友好标签。
<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兼容。关于templates - Scala/Lift-试图了解Lift同时宣称使用有效html和升降机倾向: tags and tag rewriting in render，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/6445679/