On Mar 6, 11:35 am, David Pollak <[email protected]> wrote: > Please allow me to rebut your thoughtful post.
I'm really glad to see David taking a more reasoned response to this criticism compared to the early responders . . . > Okay... sorry... but this is a gratuitous swipe. Ugly == Not Easy to Use. > Nope. Sorry. I don't buy this. Maven commands that wont copy and paste correctly == Not Easy To Use. How long had that getting started document been broken before it got fixed (assuming it's fixed now)?. Lift code problems tend to get fixed really quickly . . . documentation bugs, especially in the first document people are likely to read, should be just as much of a priority. > We will be moving to sbt post Lift 2.0, but right now, Maven is the best > option as a default. > I'm really glad to hear that there will be an official move to SBT, but I think it's the better choice now - we were seriously about ready to give up on scala /lift until we tried SBT. Maven doing full recompiles + full test runs by default is downright painful for people coming from a dynamic language background (yes, there are ways around this with mvn, but they're non-obvious to newcomers). I don't see a "how to use SBT" or "how to make Maven suck less" page in the wiki, can I write one? > Yeah. You have String constants in Rails code all the time. Plus, you have > a non-trivial amount of logic in ERBs. Plus you have to worry about > escaping Strings when you output them in an ERB template. > > In Lift, if you want, you can load templates and bind variables into the > templates, it's super-easy. And all of Lift's template loading goes through > Lift's localization mechanism. > > So, for prototypes, put your HTML literals in your code. When the team is > big enough to divide the work, go through and pull out the literals into > template files. Yeah, this violates a little of the "a prototype is > shippable" that I was talking about above, but you can also start with "best > practices" in terms of the templating. Sorry, but this, and the earlier defenses of markup in code, comes across as rationalization. Yes, snippet code is code, I don't want an html designer editing it. Yes, markup in code is better than code in markup, but that doesn't make it okay. Purely from a pragmatic point of view, that means you have to police developers putting markup in code, because xml literals outside of templates are not easily localizable. If a method in SHtml takes a user-visible string or NodeSeq, they're going to use it and stick markup directly in the code, rather than figuring out how to deal with nested binds or whatever. Separation of concerns, at least in the blunt markup vs code sense, is IMHO one of the biggest selling points of Lift . . . yet the examples and the lift book (and to a certain extent the design of lift itself) encourage putting markup in snippet code. Show people how to do it the right way. To the OP, taking the time to explore lift further is worth it if you're doing i18n / comet or just want to try a static language. If you want a sinatra-alike (ie less verbose than Lift, restful by design) that runs more-natively on the JVM, look at Compojure. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
