比赛与提升痛点

Question

编辑
缓慢的编译时间现在可以通过子项目启用的构建大大减轻,这是一个巨大的胜利.

已经从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/foo/bar /:id与DELETE/foo/bar /:id冲突,因此似乎不支持REST; 即路径路径必须是唯一的,可能是反向路由.

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

3)视图:每个foo动作使用scala.html文件,文件计数增长很快,这意味着构建时间越慢,编译越多; 由于缺乏IDE支持而不支持泛型和盲编码(当然,迄今为止没有scala模板引擎具有IDE支持,AFAIK)是特别棘手的领域.

使用Lift,HTML代码只是HTML(没有特殊符号),所以它根本不会影响编译时间.HTML(称为模板)由转换NodeSeq => 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,不包含符号或标记.您可以使用设计师按原样放置的内容,甚至可以直接访问它们进行更新(在某些情况下无论如何).

另一方面,片段是纯Scala,而不是一些模板语言.无论你使用Scala做什么,你都可以在一个片段中完成,并且所有这些都由编译器检查.

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

4)增量构建工作,但过程中的任何内容都不能称为"snappy",即使对scala.html文件进行简单更改,实际上也需要@ 2秒,这是很长一段时间,当你想要即时代码时 - 更改浏览器刷新反馈周期.

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

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

是否需要高级Scala？不,我不相信.这有点主观,但你可以从我发布的内容中看到,创建一个模板并将代码片段应用到它是非常简单的.你必须熟悉像"map"这样的概念,但如果不是,那么使用Scala Web框架会有什么好处呢？关于你将使用的一些方法的Scala文档可能看起来像初学者一样多毛,但很像Scala集合,复杂性使得库更容易使用.对于人谁是新的斯卡拉,他们很可能掉在下面的例子更好的Wiki的食谱和简单的提起,而不是API文档,但我认为这是一个成语斯卡拉,没有电梯的.

你需要在"控制器"中混合标记吗？绝对不.我将要看看Lift不是MVC框架,并假设海报正在讨论Snippets.从代码段输出HTML绝不是必需的,并且在大多数情况下是完整的反模式.像我发布的CSS选择器允许您将所有HTML保存在模板文件中,并将所有逻辑保存在Snippets中.

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

Answer 2

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

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

我对电梯的体验来自几年前,所以有些观点可能不适用:

• 代码库和语法(Lift的来源)实际上是高级Scala.这使得在Scala中启动的人在查看框架代码时很难掌握代码所做的事情.
• 视图优先方法是一个混乱,混合代码在"控制器"(返回HTML),它打破了关注点的分离,并使代码更难一点

但最重要的是:

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