The four you've listed fall into 2 groups: full-stack (lift and play)
and minimal (scalatra and unfiltered). Are you a full-stack or minimal?
Decide and you are half way to your answer. If you think a framework
should provide rich layers over key technologies including your
protocol, data store, presentation, and state management, then you want
full-stack. Such frameworks are fine, but it is incumbent upon you to
have an intimate understanding of how such frameworks abstract over this
infrastructure, as well as the infrastructure itself. Some will disagree
with that, arguing that the very reason you want these abstractions is
so you don't need this understanding. If you buy that then I wish you
luck; you'll surely need it should you decide to develop a non-trivial
application.
The other two, scalatra and unfiltered, are much lighter. These are
similar in that they provide a syntactic abstraction for working with
http, but intentionally avoid abstracting it away. Instead the embrace
the protocol and keep it front and center. This naturally makes some
tasks more involved (like state management), but such tools make it
easier to wield http, instead of wrangle it into something it isn't.
Additionally, because they're so small and so bound to the medium,
they're much easier to learn.
I've worked a fair bit with lift and play in the past. I like lift's
component-like architecture but found it generally obtuse. I found play
much easier to get started with, and if you're a RoR-flavored MVC type,
it's definitely a good choice. Both pack abstractions over http and come
with ORMs, view and state management out of the box. That said, I'm not
sure I would choose to use either of these simply because I'm more
minimal. In my experience I've found that the bigger the framework, the
bigger the chance of it getting in your way.
I work full time on a mid-sized web app built entirely with unfiltered.
I've worked with unfiltered in some manner since it surfaced, and for
the time being it's unlikely that I would pick something else. Why? It
simply matches my philosophy about web apps, and it leverages scala's
strength to wrap http. For example, instead of using string patterns
that the framework parses on the fly (like scalatra), unfiltered uses
partial functions to pull apart a request as a pattern match. The
library has many intuitive extractors to help you pull apart requests
based on content types, authentication headers, encoding types, and
includes a combinatorial library for sending responses in various
formats. It runs on GAE (I have two such apps deployed), standard
servlet containers, and netty.
So by now my bias is clear, but I'm not really the emotional type. I
arrived at unfiltered after years with many different frameworks, and
after having a go with both lift and play. They are fine frameworks, but
they don't match my philosophy.
-chris
The other two, scalatra and unfiltered, are much lighter. These are similar in that they provide a syntactic abstraction for working with http, but intentionally avoid abstracting it away. Instead the embrace the protocol and keep it front and center. This naturally makes some tasks more involved (like state management), but such tools make it easier to wield http, instead of wrangle it into something it isn't. Additionally, because they're so small and so bound to the medium, they're much easier to learn.
Lift claims to have a lot of security built in against stuff like
cross-site scripting and replay attacks [1], without the developer having to
do anything special or even think about it. I haven't used any of the
frameworks enough to know. Can anyone comment on this claim?
--
Jim
[1] http://seventhings.liftweb.net/ item 7
With regards to the Anorm component I am surprised to see so many people with negative opinions of it.
With regards to the Anorm component I am surprised to see so many people with negative opinions of it. As I understand it Anorm mostly just lets you query using SQL (Which is a pretty reasonableproposal if you ask me) and get back objects which are easy to work with. It's possible to do various other stuff with it, but the aforementioned feature is its key strength.
Whether or not you agree with the Anorm philosophy is just one of those things. Some people love top-heavy ORM systems and the supposed safety ropes they provide.Other people run intoproblem after problem after problem and just want something less long-winded. It's a matter of choice and I personally applaud Anorm for helping to provide that choice.Overall, I like ORMs but think the programmers working with them should still have a firm grasp of SQL. Unfortunately this is not always the case :-/
On 2 September 2011 05:52, Brian Schlining <bschl...@gmail.com> wrote:I think Chris' answer is a very good summary. I just wanted to mention I ported a mid-sized app from Wicket over to Scalatra and the resulting code base is much lighter and the code is far easer to understand. Also, the Java world has some great persistence API's that I'm familiar with so having a framework with persistence baked-in wasn't important for me. But if you're not up on one of those you might want a framework with persistence built in.Got to say unfiltered looks interesting ...~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~The other two, scalatra and unfiltered, are much lighter. These are similar in that they provide a syntactic abstraction for working with http, but intentionally avoid abstracting it away. Instead the embrace the protocol and keep it front and center. This naturally makes some tasks more involved (like state management), but such tools make it easier to wield http, instead of wrangle it into something it isn't. Additionally, because they're so small and so bound to the medium, they're much easier to learn.
--
Brian Schlining
bschl...@gmail.com
HTH,
N.
--
Noel Welsh
Untyped Ltd http://www.untyped.com/
+44 (0) 121 285 2285 in...@untyped.com
UK company number 06226466
See
http://groups.google.com/group/liftweb/browse_thread/thread/73791b1d6625116
Some of the techniques (pages are treated as DOM-like objects instead
of templates during processing) takes its toll on development. It is
really hard learn. I don't buy the argument about leaking primary
keys; it has not been a problem on any framework I've worked - It is
bad developers who leak primary keys, not the framework.
If I am to buy into it, it would not be for security bad rather that
it is the only framework built completely around Scala.Note that I am
biased because I find Lift to be too time consuming for me to learn.
I'd prefer a simpler framework like Play! In fact, I am writing a
tutorial for it now!
--
---
John L Cheng
Er...I would imagine that since Anorm involves writing actual SQL that using a transaction involves writing the actual SQL for said transaction...On 2 September 2011 07:02, Brian Schlining <bschl...@gmail.com> wrote:
Hey, I don't see that Anorm supports database transactions. Is that really true or am I missing something? (SQL without transactions seems like a pretty significant oversight ...)
I was just responding to Jim's question about Lift's security
features. Personally I like to learn more about Lift's approach to
security as well. I just wanted to start off with the information I've
come across and my thoughts on it.
I understand that Lift makes security a fundamental part of the
framework. That's a good thing. It's just when I read things like
"Lift apps leak fewer primary keys and other information than do other
apps" it smells like market speak to me. That, just a small part of
Lift's features list, was something I didn't like.
Regarding "Lift in Action", I am afraid to say I haven't read it. But
I have added it to my read it later list!
You want to use JDBC -> Api is ugly and mutable -> you wrap it into a nicer safe api -> you want to support more types -> you add typeclasses -> you get overwhelmed with parsing the same structures the same way -> you add combinators -> you get AnormI hope this explains better the picture.
If I am to buy into it, it would not be for security bad rather that
it is the only framework built completely around Scala.Note that I am
biased because I find Lift to be too time consuming for me to learn.
I'd prefer a simpler framework like Play!
I started with Lift. I liked the key concepts but was hurt by the lack
of documentation at the time (don't know if it has changed). Writing a
simple widget using Lift's JS abstraction was just a PITA, so I tried
with Scalatra. Then I looked at Play!. I believe there is some good
potential there. But I didn't need Anorm and I already wanted to keep
Scalate for my templates. Also, Play! was really in my way: I really
need to have control over sbt as the app we have in mind has some
heavy middleware. IMO, Play! doesn't let you consider that the Web is
just a part of your application.
I then looked at Scalatra and Unfiltered. I picked Unfiltered (maybe
because I knew the authors) and I don't regret it. It's really in the
Scala spirit: don't get in my way, do one thing and only one. And do
it well. I test my APIs with Dispatch, which is really good too. I was
amazed how fast I could write tricky applications, where I really care
about the HTTP stack.
Alexandre.
You want to use JDBC -> Api is ugly and mutable -> you wrap it into a nicer safe api -> you want to support more types -> you add typeclasses -> you get overwhelmed with parsing the same structures the same way -> you add combinators -> you get AnormI hope this explains better the picture.No, I don't think you understand my point. My question is: Does Anorm support transactions? I found some discussion about it on this thread: https://groups.google.com/forum/#!topic/play-framework/qA6GyRn_eew but it doesn't look like Anorm allows you to explicitly demarcate transaction boundaries. You can add all the syntactic sugar you want to make it a type-safe, combinator filled, 'nicer safer' api. But without transaction support, it's just a toy framework that I would not put into production.
case GET(UFPath("/jsonp/lift-json/optional") & Jsonp.Optional(callback)) =>callback respond {import net.liftweb.json.JsonAST._import net.liftweb.json.JsonDSL._"answer" -> Seq(42)}