Question

修改
慢速编译时间现在在很大程度上通过sub project启用的构建来缓解，这是一个巨大的胜利。

已离开Play的内置资产生成器（即Coffeescript和LESS）并转移到第三方Grunt JS;现在增量构建期间的代码更改仅受scalac编译时间的限制，而不受Play相对较慢的资产生成的开销限制。

ORIGINAL
Play 2.1 Scala（2012年9月14日发布，就在转换到Scala 2.10之前）总体上非常满意;然而，有一些发展的痛点：

1）路由：在路由改变时，一个人的整个路由控制器结构   can被重新编译：不好。

2）自路由POST /foo/bar/:id以来，似乎没有直接支持REST   与DELETE /foo/bar/:id冲突;即路径路径必须是唯一的，   大概是为了反向路由。

3）视图：每个foo动作使用scala.html文件，文件数量会增加   很快，这意味着更慢的构建时间，更多的编译;仿制药没有   由于缺乏IDE支持而支持和盲编码（当然没有   scala模板引擎迄今为止IDE支持，AFAIK）是特别棘手的领域。

4）增量构建工作，但不能调用过程中的任何内容   “snappy”，即使对scala.html文件进行简单更改也会实际   需要@ 2秒，这是你想要那个瞬间的很长一段时间   代码更改浏览器刷新反馈周期。

我知道Play开发人员正在研究上述一些问题，而且慢速构建时间也与sbt，scala版本和自己的代码结构直接相关。总的来说，Play一直是一种愉快的开发体验。然而，这是关于痛苦的，我想知道Lift在这方面带来了什么......

Lift似乎采取了不同的方法。升降机是否会受到以上物品的影响？假设没有，因为MVC，Lift不是，并且xml样式的片段方法可能不会产生与Play的幕后构建机制相同的编译时间。

Lift有什么痛点？

Answer 1

我自己的个人观点，因为现在已经使用Lift大约2年了：

1）路由：在路由改变时，是整个路由控制器结构可以重新编译：不好

使用Lift，没有路由。我认为最接近的相关概念是SiteMap，而且我个人从来没有遇到任何与它编译相关的问题。

2）自路由POST以来，似乎没有直接支持REST / foo / bar /：id与DELETE / foo / bar /：id冲突;即路径必须是唯一的，大概是反向路由。

使用Lift完成了很多REST，我可以告诉你这绝对不是问题。 Lift的REST支持为really nice，基于Scala的模式匹配，为您提供了一种非常强大，类型安全的Web服务设计方式

3）视图：每个foo动作使用scala.html文件，文件数量会增加很快，这意味着更慢的构建时间，更多的编译;仿制药没有由于缺乏IDE支持而支持和盲编码（当然没有 scala模板引擎最近有IDE支持，AFAIK尤其如此艰难的地区。

使用Lift，HTML代码只是HTML（没有特殊符号），所以它根本不会影响编译时间。 HTML，称为模板，由转换NodeSeq =＆gt;的片段处理。 NodeSeq。这可能听起来很复杂，但是Lift有一个DSL可以让它变得非常简单。想要在跨度中添加用户名？如果它看起来像：

<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行的表，每行代表列表中元素的名称/值。

我认为这实际上是Lift最大的优势之一。模板只是HTML，不包含符号或标记。您可以使用设计师按原样放置的内容，甚至可以直接访问它们进行更新（在某些情况下无论如何）。

另一方面，

Snippets是纯Scala，而不是一些模板语言。无论你使用Scala做什么，你都可以在一个代码片段中完成，并且所有内容都由编译器检查。

也可以（并鼓励）在多个网页上使用代码段，因此您不必每页都需要一个代码段。您甚至可以将站点地图配置为对多个页面使用相同的模板，并根据请求将类型安全参数传递给页面包含的代码段。

4）增量构建工作，但不能调用过程中的任何内容＆＃34; snappy＆＃34;，即使对scala.html文件进行简单更改也会实际需要@ 2秒，这是你想要那个瞬间的很长一段时间代码更改浏览器刷新反馈周期。

我不认为Lift会在这方面受到伤害，但不幸的是，它也没有多大帮助。很高兴听到Scala 2.10将在这方面进行一些改进，因为我认为它们必须来自编译器。

回答一些提升批评......

是否需要高级Scala？不，我不相信。这有点主观，但您可以从我发布的内容中看到，创建模板并将代码片段应用于其中非常简单。您必须熟悉＆＃34; map＆＃34;等概念，但如果您不是，那么使用Scala Web框架有什么用呢？关于您使用的某些方法的Scala文档对于初学者来说可能看起来有些毛茸茸，但与Scala集合很像，复杂性使得库更容易使用。对于刚接触Scala的人来说，他们可能最好关注Wiki Cookbook和Simply Lift中的示例，而不是API文档，但我认为这是Scala成语，而不是一个电梯。

你是否必须在＆＃34;控制器中混合标记＆＃34;？绝对不。我将回顾一下Lift不是MVC框架的事实，并假设海报正在讨论Snippets。从代码段输出HTML绝不是必需的，并且在大多数情况下是完整的反模式。像我发布的CSS选择器允许您将所有HTML保存在模板文件中，并将所有逻辑保存在代码段中。

Lift需要太多状态吗？这是我遇到的头号投诉，而不是一次我看到它伴随着现实世界的问题。事实是，通过Lift，您可以选择是否要成为有状态。如果您使用Lift编写Web服务，并且您不希望在访问URL时创建会话，则使用LiftRules.statelessDispatchTable注册该服务。这符合Lift的理念，即状态既不好也不坏，但它是满足某些需求所必需的，而不是其他需要的必要条件。明确何时使用并让开发人员决定是非常重要的。如果您对此有更详细的兴趣，David Pollack有better explanation。

Answer 2

首先，我相信你能解决一些问题是公平的：

On 1和4：Scala 2.10在编译速度方面有相关的提升，这应该不再是问题了
On 2：从未发现与GET / POST有任何冲突，但我没有尝试删除。可能是Play或您的代码中的错误（打开一个新问题，包括完整的路线定义，包括方法）
On 3：IntelliJ 12支持Play 2.模板AFAIK支持泛型（如果通用你的意思是传递X [A]或A类型的泛型参数）

我对电梯的经验来自几年前，所以有些观点可能不适用：

代码库和语法（Lift的来源）实际上是高级Scala。这使得在Scala中启动的人在查看框架代码时很难掌握代码所做的事情。
视图优先方法很混乱，在“控制器”中混合代码（返回HTML），它打破了关注点的分离并使代码变得更加困难

但最重要的是：

有状态。自从我离开Java EE世界并开始使用无状态服务器以来，已经消失的问题数量惊人。不必担心会话和其他混乱似乎无关紧要，但它确实有所作为。特别是在云计算时代：）

比赛与提升痛点

2 个答案: