哪种类型的 Web 应用程序最适合 Scala Lift 框架？
什么样的应用程序最适合 Scala 的 lift Web 框架。
我的要求：
- 易于开发和可维护性
- 准备用于生产目的。即良好活跃的在线社区、定期补丁和安全更新以及性能修复等。
- 框架应该可以生存几年。我不想在一年后没有可用更新/补丁的框架中编写应用程序。
- 拥有良好的 UI 模板引擎
- 与 Java 的互操作（Scala 满足了这一点。为了完整起见，在这里仅提及）
- 良好的面向组件的开发。
- 开发所需的时间应与 Web 应用程序的复杂性成正比。
- 不应该完全基于配置。我讨厌自动为我生成代码并在幕后执行各种魔法。这是调试的噩梦。
- 开发 Web 应用程序所需的 Lift 知识量应与 Web 应用程序的复杂性成正比。即我不应该为了开发一个简单的 TODO 应用程序而花费 10 多个小时学习 Lift。 （我有数据库、Scala 方面的知识）
Lift 满足这些要求吗？
What kind of applications are the sweet spot for Scala's lift web framework.
My requirements:
- Ease of development and maintainability
- Ready for production purposes. i.e. good active online community, regular patches and updates for security and performance fixes etc.
- Framework should survive a few years. I don't want to write a app in a framework for which no updates/patches are available after 1 year.
- Has good UI templating engines
- Interoperation with Java (Scala satisfies this arleady. Just mentioning here for completeness sake)
- Good component oriented development.
- Time required to develop should be proportion to the complexity of web application.
- Should not be totally configuration based. I hate it when code gets automatically generated for me and does all sorts of magic under the hood. That is a debugging nightmare.
- Amount of Lift knowledge required to develop a webapp should be proportional to the complexity of the web application. i.e I should't have to spend 10+ hours learning Lift just to develop a simple TODO application. (I have knowledge of Databases, Scala)
Does Lift satisfy these requirements?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
好吧，您可以浏览 Lift 入门 指南，在其中构建 Ajax To Do 应用程序 ;-)
Lift已经存在 3 1/2 年了。 Google Group 拥有近 2,000 名员工。有 40 名提交者，其中每月有 10 多个提交。我们每月关闭 40 到 80 个门票，每月进行里程碑发布。 FourSquare、Xerox 和 Novell 等公司都拥有基于 Lift 构建的核心应用程序。
Well, you could cruise through the Lift getting started guide in which you build an Ajax To Do app ;-)
Lift has been around for 3 1/2 years. The Google Group has nearly 2,000 people on it. There are 40 committers, of whom, 10+ make commits each month. We close between 40 and 80 tickets per month, do monthly milestone releases. Companies like FourSquare, Xerox, and Novell have hardcore apps built on Lift.
恕我直言，电梯满足这些要求。但另一方面，对#4 不太确定，它有一个很好的后端集合来与其他服务交互。
我认为这主要取决于复杂性。 Lift 以自己的方式做事，您可能很容易做到，也可能不容易。我会花一天时间来编写该 TODO 应用程序 - 并且一定要使用liftweb 群组< /a>，因为 Stack Overflow 上的 Lifters 并不多——看看情况如何。我想你只要一天就能对此形成意见。
IMHO, Lift meet those requirements. Not so sure about #4, though, on the other hand, it has a good collection of back ends to interact with other services.
I think it mostly hinges on complexity. Lift does things its own way, which you may get easily, or you may not. I'd take a day to write that TODO application -- and be sure to make use of the liftweb group, as there just aren't many Lifters on Stack Overflow -- and see how that goes. I think you'll be able to form an opinion on it -- just a day.
关于最佳点：http://seventhings.liftweb.net/
On sweet spots: http://seventhings.liftweb.net/
我认为您也应该将其发布到 lift 邮件列表中：
http://groups.google.com/group/liftweb
i think you should post this in the lift mailing list too:
http://groups.google.com/group/liftweb
阅读 seventhings.liftweb.net 并浏览 Lift in Action 的前两章后，Lift 的最佳点似乎是、复杂的基于 HTML 页面的应用程序，具有高级客户端功能（如 Facebook 和 Twitter）。
与单页 ajax“webapp”应用程序相比 (像日历，或者主要是任何使用 ExtJS 构建的东西）提供高级功能客户端功能具有纯 javascript 和 ajax 中间层服务，但编程模型是 javascript，html 被抽象出来。还可以与传统的基于 HTML“网站”的应用程序（例如 wiki 或博客）进行比较（例如 twitter bootstrap + jquery），它们不需要高级的客户端功能。
我认为单页 Web 应用程序和基于页面的网站使用 Lift 会变得比必要的更加复杂，除非您有经验丰富的人员。纪律严明的团队。这可能与产品成熟度和团队规模相关 - Facebook 和 Twitter 是非常大型的应用程序，拥有数百个互动团队和强大的工程领导力。
我认为，一个仍在探索各种应用程序的结构并形成意见的小团队很可能会被 Lift 误导，采用更复杂的解决方案，而他们所需要的可能只是简单的 HTML 模板和简单的 ajax 端点。
After reading seventhings.liftweb.net and skimming the first two chapters of Lift in Action, Lift's sweet spot looks to be, complex HTML page-based applications with advanced client-side functionality (like Facebook and Twitter).
Compare to single-page ajax "webapp" applications (like a calendar, or mostly anything built with ExtJS) that provide advanced client-side functionality with pure javascript and ajax middle tier services but the programming model is javascript, html is abstracted away. Compare also to traditional HTML "website" based applications like a wiki or blog -- think twitter bootstrap + jquery -- that don't need advanced client-side functionality.
single-page webapps and page-based websites i think would be made more complex than necessary with Lift unless you had an experienced & disciplined team. This probably correlates with product maturity and team size - facebook and twitter are extremely large applications with hundreds of interacting teams and strong engineering leadership.
a small team of people still exploring and forming opinions on how various apps should be structured is likely, i think, to be mislead by Lift into more complex solutions when perhaps all they needed was straightforward HTML templates and simple ajax endpoints.