问玩与举痛点

EN

我个人的观点是，作为一个已经使用电梯大约两年的人：

1)路由:在路由改变时，可以重新编译整个路由控制器结构:不太好。

有了电梯就没有路线了。我认为最密切相关的概念应该是SiteMap，而就我个人而言，我从来没有遇到过与它的编译相关的任何问题。

2) REST似乎不被直接支持，因为路由POST /foo/bar/:id与DELETE /foo/bar/:id冲突；也就是说，路由路径必须是唯一的，大概是用于反向路由。

在做了相当多的休息后，我可以告诉你，这绝对不是一个问题。Lift的REST支持是真的很好，基于Scala的模式匹配，它为您提供了一种非常强大、类型安全的设计web服务的方法

3)视图:对于每个foo操作都有一个scala.html文件，文件数量增长很快，这意味着构建时间更慢，编译时间更长；泛型不受支持，以及由于缺少IDE支持而导致的盲目编码(当然，scala模板引擎目前还没有支持IDE，AFAIK)是特别困难的领域。

使用Lift，HTML代码只是HTML (没有特殊的符号)，所以它根本不考虑编译时间。HTML，称为模板，是由转换NodeSeq => NodeSeq的片段处理的。这听起来可能很复杂，但是Lift有一个DSL来使它变得非常容易。要向span添加用户名吗？如果看起来是：

<span id="user-name">User name goes here</span>

在你的代码片段中会有这样的代码：

"#user-name *" #> user.name

还可以重复模板中的项，如表或列表：

​

<table id="table"><tr><td class="name"></td><td class="value"></td></tr></table>

​

在此情况下：

val tuples = List(("Lift", "Is great"), ("Other web frameworks", "Eh"))
"#table" #> {
  "tr" #> {
     tuples map { case(name, value) =>
       ".name" #> name &
       ".value" #> value
     }
  }
}

将产生一个有2行的表，每一行重新表示列表中一个元素的名称/值。

我认为这是电梯最大的优点之一。模板只是HTML，没有包含符号或标记。您可以使用您的设计人员组合在一起的内容，甚至允许他们直接访问进行更新(在某些情况下无论如何)。

另一方面，代码片段是纯Scala，而不是某种模板语言。无论您能用Scala做什么，您都可以在代码段中这样做，所有这些都由编译器检查。

还可以(并鼓励)在多个页面上使用代码段，因此每个页面不一定需要一个片段。您甚至可以将Sitemap配置为对多个页面使用相同的模板，并根据请求将类型安全参数传递给页面包含的片段。

4)增量构建工作，但过程中没有任何东西可以称为"snappy"，即使是对scala.html文件的简单更改实际上也需要@2秒，当您想要即时更改浏览器-刷新反馈周期时，这是一个很长的时间。

我不认为电梯在这方面很疼，但不幸的是，它也没有多大帮助。很高兴听说Scala2.10将包括这方面的一些改进，因为我认为它们必须来自编译器。

来回答一些关于电梯的批评..。

高级Scala是必需的吗？不，我不相信。这有点主观，但从我发布的文章中可以看出，创建一个模板并将一个片段应用到模板上是非常直接的。您必须熟悉诸如"map“这样的概念，但是如果不熟悉Scala web框架，那么使用它有什么好处呢？对于第一次使用的方法，Scala文档可能看起来有点毛茸茸，但与Scala集合非常相似，其复杂性是为了使库更易于使用。对于刚开始使用Scala的人来说，他们最好学习维基 -- 烹饪书和简单举升，而不是API文档中的例子，但我认为这是Scala的成语，而不是Lift成语。

你必须在“控制器”中混合标记吗？绝对不是。我将忽略Lift不是MVC框架的事实，并假设海报是在讨论代码片段。从片段输出HTML并不是必要的，而且在大多数情况下都是一个完整的反模式。我发布的CSS选择器允许您将所有HTML保存在模板文件中，并将所有逻辑保存在代码段中。

电梯是否需要太多的状态？这是我遇到的头号抱怨，我从来没有见过它伴随着一个现实世界的问题。事实是，对于电梯，你可以选择你是否想成为有状态的。如果您正在使用Lift编写web服务，并且不希望在访问URL时创建会话，则可以向LiftRules.statelessDispatchTable注册该服务。这符合电梯哲学，即国家既不是好的也不是坏的，但它必须满足一些需要，而不是其他必要的。重要的是要明确什么时候使用它，让开发人员来决定。如果你对这方面的更多细节感兴趣，大卫·波拉克有一个更好的解释。

首先，我认为你的一些观点是公平的：

• 关于1和4: Scala2.10在编译速度上有了相应的提高，这应该不再是一个问题了
• On 2:从未见过与GET/POST有任何冲突，但我没有尝试删除。可能是游戏中的错误或代码中的错误(打开一个新问题，包括完整的路由定义，包括方法)
• On 3: IntelliJ 12支持Play 2。模板AFAIK支持泛型(如果泛型的意思是传递XA或A类型的泛型参数)

我在电梯方面的经验是从几年前开始的，因此其中一些要点可能不适用：

• 代码库和语法(Lift的源代码)实际上是高级Scala。这使得从Scala开始的人在查看框架代码时很难理解代码在做什么。
• 视图优先的方法是混乱的，将代码混合在“控制器”中(返回HTML)，它打破了关注点的分离，使代码的执行更加困难。

但最重要的是：

• 有状态的。自从我离开Java世界并开始使用无状态服务器之后，已经消失的问题之多令人震惊。不必担心会议和其他杂乱无章的事情似乎无关紧要，但这确实产生了影响。特别是在云计算时代:)