Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><em>Let's assume we're equally comfortable in Scala and Java, and ignore the (huge) language differences except as they pertain to Spring or Lift.</em></p> <p>Spring and Lift are almost diametrically opposed in terms of maturity and goals.</p> <ul> <li>Spring is about five years older than Lift</li> <li>Lift is monolithic and targets only the web; Spring is modular and targets both web and "regular" apps</li> <li>Spring supports a plethora of Java EE features; Lift ignores that stuff</li> </ul> <p>In a sentence, Spring is heavyweight and Lift is lightweight. With sufficient determination and resources you can turn that on its head, but you would need a <em>lot</em> of both.</p> <p>Here are concrete differences that stuck in my mind after working with both frameworks. This isn't an exhaustive list, which I can't compile anyhow. Just what seemed most interesting to me...</p> <ol> <li><p>View philosophy</p> <p>Lift encourages placing some view material in snippet/action methods. Snippet code especially will be sprinkled with programmatically generated form elements, <code>&lt;div&gt;</code>s, <code>&lt;p&gt;</code>s, etc.</p> <p>This is powerful and useful, especially since Scala has a builtin language-level XML mode. One can write XML inline within Scala methods, including variable bindings in braces. This can be delightful for very simple XML services or mockups of services -- you can bang out a suite of HTTP response actions all in one splendidly terse file, without templates or much attendant configuration. The downside is complexity. Depending on how far you go, there's either a fuzzy separation of concerns between view and logic, or no separation.</p> <p>In contrast, regular use of Spring for webapps enforces a strong separation between the view and everything else. I think Spring supports several templating engines, but I've only used JSP in anything serious. Doing a Lift-inspired "fuzzy MVC" design with JSP would be madness. This is a good thing on larger projects, where the time to just read and understand can be overwhelming.</p></li> <li><p>Object-Relational Mapper Choices</p> <p>Lift's builtin ORM is "Mapper". There's an upcoming alternative called "Record", but I think it's still considered pre-alpha. The LiftWeb Book has sections on using both Mapper and JPA.</p> <p>Lift's <a href="http://neuralmonkey.blogspot.com/2009/08/simple-lift-crud.html" rel="noreferrer">CRUDify</a> feature, cool as it is, only works with Mapper (and not JPA).</p> <p>Of course, Spring supports a <a href="http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/orm.html#orm-introduction" rel="noreferrer">panoply of standard and/or mature database technologies</a>. The operative word there is "supports". Theoretically, you can use any Java ORM with Lift, since you can call arbitrary Java code from Scala. But Lift only really supports Mapper and (to a much lesser extent) JPA. Also, working with nontrivial Java code in Scala is currently not as seamless as one might like; using a Java ORM, you will probably find yourself either using both Java and Scala collections everywhere or converting all collections in and out of the Java components.</p></li> <li><p>Configuration</p> <p>Lift apps are configured pretty much entirely through a method an application-wide "Boot" class. In other words, the config is done through Scala code. This is perfect for projects with brief configurations, and when the person doing the configuring is comfortable editing Scala.</p> <p>Spring is pretty flexible in terms of configuration. Lots of conf options can be driven either through XML configuration or annotations.</p></li> <li><p>Documentation</p> <p>Lift's documentation is young. Spring's docs are pretty mature. There's no contest.</p> <p>Since Spring's docs are already nicely organized and easy to find, I'll review the docs I found for Lift. There are basically 4 sources of Lift documentation: the <a href="http://groups.google.com/group/the-lift-book/" rel="noreferrer">LiftWeb Book</a>, the <a href="http://scala-tools.org/scaladocs/liftweb/1.0/" rel="noreferrer">API Docs</a>, LiftWeb's <a href="http://groups.google.com/group/liftweb" rel="noreferrer">Google group</a>, and "<a href="http://liftweb.net/docs/getting_started/mod_master.html" rel="noreferrer">Getting Started</a>". There's also a nice suite of code examples, but I wouldn't call them "documentation" per se.</p> <p>The API docs are incomplete. The LiftWeb Book has been published on trees, but it's also freely available online. It is really useful, although its decidedly didactic style irritated me at times. It's a little long on tutorial and short on contract. Spring has a proper manual, which Lift lacks.</p> <p>But Lift does have a nice set of examples. If you're comfortable reading the Lift code and example code (and you know Scala well already), you can work things out in fairly short order.</p></li> </ol> <p>Both frameworks are compelling. There's a broad range of apps where you can choose either and do well.</p>
    singulars
    1. This table or related slice is empty.
    1. POWhy would I use Scala/Lift over Java/Spring?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USDan LaRocque
    1. USDan LaRocque
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhy would I use Scala/Lift over Java/Spring?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COA good answer, one point I'd disagree on though is: Spring being heavyweight. It's got a broad range of good APIS, and imposes certain structural ways of working necessary to get a good outcome to it, but compared to the J2EE stuff it originally replaced it's a much more lightweight solution. Of course "lightweightness" is in the eye of the beholder, so this is definitely a subjective argument. Just my 2 cents then.
      singulars
      1. PO
      1. USBrian
    2. COGood Answer, very objective. Lift does too much seemingly smart things, which are very stupid. Moving page logic to backend, mixing HTML to scala code, which is worse than control tags inside page template. I don't know why they did this, perhaps they think Scala must process XML stunningly fast. "The Definitive guide to Lift" is the worst tech book I've ever read.
      singulars
      1. PO
      1. USSawyer
    3. COI'm not as familiar with lift as I would like to be. In your opinion how difficult would it be to make a wrapper for the boot object that instead reads settings in from an xml file? My first impression is that since scala handles xml so well out of the box, it wouldn't be exceptionally difficult.
      singulars
      1. PO
      1. USApe-inago
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload