date:20100306



On 6 mar., 06:43, cageface milese...@gmail.com wrote:
 Like many other web developers, I abandoned some heavyweight Java web
 frameworks about 6 years ago for Rails and have been working pretty
 much exclusively in Rails ever since. However, I've always had a
 secret lust for functional languages so when I heard about Scala and
 Lift I decided to take a closer look. My first impression of the
 community from studying this list and many other blogs, articles etc
 is that it's a group of smart, dedicated folks that have generously
 dedicated a lot of time and energy to making Lift a first-class
 alternative to the more conventional options.

 However, my first brush with the framework itself has so far left a
 very different impression. I think one of the reasons Rails caught on
 so quickly in the beginning was that it was marketed brilliantly. DHH
 made Rails look so simple, stylish and intuitive that anybody drowning
 in the bulk and complexity of Java web dev at the time couldn't help
 but take notice. Lift, in contrast, and particularly for anybody with
 a prior history in Java, seems very daunting and rough. The following
 impressions are very much superficial first impressions and may really
 have no deeper substance than that but I think first impressions count
 for a lot in this sphere.

 First, the liftweb.net site is nice. It's a clean, elegant,
 contemporary design. So far so good. Let's click on getting started.
 What's this? PDF? Who uses PDF? Nevermind, let's look at the HTML.
 Gack! This looks like an academic LaTEX conversion from the 90s.
 Layout and formatting are next to non-existent. This doesn't look like
 the intro for a simple, ready-to-use tool.

 Oh well, pushing past the wall of text intro we discover that we need
 Maven. Alarms are starting to go off in the heads of many Java
 refugees that remember Maven as the nadir of the XML-situp
 overabstracted agony that was pre-Rails Java web dev. I imagine many
 people have signed off by this point. We go download maven and press
 on to the first actual command we can run, which is an impressively
 cryptic 8-line mvn invocation that seems to take about 10 minutes to
 download every single apache and codehaus jar file.

 When this finally winds down we start the server and take a look at
 our homely start page and bounce back to the docs. XHTML. Hmmm. Didn't
 everybody give up on that a few years ago?

Lift is not a MVC framework - it is rather a View First framework. It
intentionally avoids putting code in the template. This keeps the
template clean. Xhtml in Scala? YES ! because:

1. Snippets are UI complementers ... putting xhtml in other app layers
is your application design responsibility
2. Scala supports xml literals which makes in practice this paradigm
extremely useful and clean
3. It respects separation of concerns because the template itself
and the snippets have the same concern - rendering static
respectively dynamic content. Putting code inside the template is one
of the worse design decisions ever. Putting template fragments inside
Scala code makes tremendous sense as it allows a truly flexible way of
achieving compositionality, reusability etc.

whether you abuse this or not is your choice, but every framework has
element that can be abused leading to really poor design.


HTML literals *in* the
 code? All the snippets we're going to be editing live six levels
 deep in the project directory structure? This will be fun with emacs/
 vim...

Actually I'm using emacs like many other folks. It is a very good
experience and I'm happy with it.


 By this point our enthusiasm is seriously waning but our dreams of an
 expressive but statically typed platform keep us going on to the next
 section anyway. We begin with another mvn invocation that mysteriously
 fails. After futzing with it for a bit and googling around we discover
 that there are spaces following each of the \ line continuations so we
 copy and paste the whole thing into a file, clean it up, and invoke it
 via sh. After this finishes we create the first model, which actually
 looks pretty reasonable, similar to a Django model with a little more
 boilerplate but nothing too intimidating. We discover to our chagrin
 that we're going to have to manually add each model to the toplevel
 Schemifier invocation in Boot.scala, which makes us grumpy. We skim
 through the explanation of the views and we're not sure what to make
 of the html binding approach. On one hand it looks pretty precise. On
 the other hand it suggests an even tighter straightjacket than Django
 templates. We reserve judgement.

 We work through the next few instructions to come to the creation of
 TD.scala only to be greeted by a *19* line file header:
 package com.liftworkshop.snippet

 import com.liftworkshop._
 import model._

 import net.liftweb._
 import http._
 import SHtml._
 import S._

 import js._
 import JsCmds._

 import mapper._

 import util._
 import Helpers._

 import scala.xml.{NodeSeq,

Re: [Lift] superficial first impressions from a rails junkie

2010-03-06 Thread Francois Armand


Le 06/03/2010 06:58, Warren Henning a écrit :

tl;dr

Want a cookie for your efforts?

If you don't like Lift, don't use it. Problem solved. Hooray, turkey
for everyone!



I don't think that this type of email that is really constructive, and 
I'm little surprised at it, Lift community is usually nice and hears 
open for newcomers


Cageface took the time to write a (long) email about what he feels as a 
newbe on lift, and that's really valuable. Most of us just don't 
remember what was our first steps and first surprises and wtf? when we 
discovered Lift, so it's good to have someone to remind them thought 
it's fresh looking.


Most of his concern are valuable, and I can see that they are centred 
around one main point: better introduction material/documentation. I 
know that Lift make an heavy use of this mailing list, but Lift also 
need some reference manual. I believe that without the inline version of 
the Lift Book, I would have give up in a matter of days.


This kind of reference material may explain why there is XML in code, 
and why it's good - I remember that when I first looked at Lift and saw 
that, I really thought it was madness. Now, not only I see the point, 
but I love it, because it's so good to use it for dynamic content and 
ajax stuff, Scala has dynamic literals, etc. But it *was* realy 
surprising at first.


The import point was also something disturbing when I started, maven is 
a monster for Javaists who remind only maven 1 / firsts maven 2, and 
even if now, it's far better than that, it's still a big complex thing 
that deserve it's own learning effort.


And so on.

And perhaps that all that knowledge is already available online, and in 
that case, it's just a matter of reorganising the Lift site.


Cheers,

--
Francois Armand
http://fanf42.blogspot.com

--
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] superficial first impressions from a rails junkie

2010-03-06 Thread Jeppe Nejsum Madsen

cageface milese...@gmail.com writes:

[lots of stuff about layout]

I agree and as Marius wrote it's (the website at least) is a known issue
and is being worked on. But it's moving slowly.

I think the underlying problem here is that the Lift committers are
mostly code geeks and not really into the visual aesthetics. Maybe this
is a difference from the Rails community: I think a lot (not all of
course) of Lift's users have a Java background which is usually not
connected with great visual artwork. But many of the Rails guys (the few
I've talked to at least), seems to come from design studios etc. where
there's very much focus on design.

So if someone in the Lift community has the skills to help out in this
area that would be awesome :-)

We can talk technical merits all day long, but at the end of the day I
think first impressions matter for wider adoption.

 Oh well, pushing past the wall of text intro we discover that we need
 Maven. Alarms are starting to go off in the heads of many Java
 refugees that remember Maven as the nadir of the XML-situp
 overabstracted agony that was pre-Rails Java web dev. I imagine many
 people have signed off by this point. We go download maven and press
 on to the first actual command we can run, which is an impressively
 cryptic 8-line mvn invocation that seems to take about 10 minutes to
 download every single apache and codehaus jar file.

I don't like maven either, but you're not forced into using maven. But
since all tutorials use it you may get that impression. I have a blog
post waiting for a simpler (albeit less powerful) way to get started.

 When this finally winds down we start the server and take a look at
 our homely start page and bounce back to the docs. XHTML. Hmmm. Didn't
 everybody give up on that a few years ago? HTML literals *in* the
 code? 

Marius already addressed this and I agree with him :-)

 All the snippets we're going to be editing live six levels deep in
 the project directory structure? This will be fun with emacs/ vim...

No one is forcing you to have a six level deep directory structure. The
src/main/scala prefix is a maven convention. But I think it makes sense.

In my latest projects I've dropped the usual java package conventions of
com.company.project and now just use project. Works out nicely.

[...]

 And at this point we give up and start quickly paging through the rest
 of the tutorial only to come to this:
 object priority extends MappedInt(this) {
override def defaultValue = 5

override def validations = validPriority _ :: super.validations

def validPriority(in: Int): List[FieldError] =
if (in  0  in = 10) Nil
else List(FieldError(this, bPriority must be 1-10/b))

override def _toForm = Full(select(ToDo.priorityList,
 Full(is.toString),
 f = set(f.toInt)))
  }

 and we suddenly find a new appreciation for :validates_numericality_of

I don't know it, but you could probably write the equivalent validation
function in Lift. Remember, Lift is still relatively young compared to
Rails. It won't have all the bells  whistles yet.

 and we also wonder why our model should be specifying it's
 representation in the form and we decide to go googling for whatever
 the Scala equivalent of Sinatra is.

I don't know Sinatra but found this description: Sinatra is a very
simple, yet powerful, Domain Specific Language (DSL) for defining
RESTful HTTP actions, and then defining how the application is going to
respond to them

This sounds awfully close to the lift-webkit module. If you don't like
the Lift ORM, don't use it. Writing a REST api with Lift is quite
clean. You could probably google for some examples.

 I apologize if this seems flippant but I really think that a lot of
 people won't even push on this far, never mind having to do the
 homework of learning the basics of scala first.  I know that docs and
 introductory materials aren't usually that much fun to work on and I
 can imagine that the framework itself is much more polished and
 sophisticated but as potential recruiting material I think this just
 isn't very good.

As I wrote earlier, I think first impressions are important. Thanks for
sharing.

I can only say that I've found Lift a joy to use and very powerful at
the lower layers. As you move up in the abstraction layers (think forms
etc) it's not as polished yet, but it has a solid foundation to build on.

/Jeppe

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] superficial first impressions from a rails junkie

2010-03-06 Thread Timothy Perrett

Firstly, Lift is not Rails. It really bugs me when people are like oh, well 
rails does XYZ. Its apples and oranges in many respects - especially when you 
consider the ages of the respective projects... Lift is much, much younger than 
Rails. Moreover, Lift is a very advanced framework -more so than its 
competitors- and we are working on distilling the experience for people who new 
to the ecosystem. We have invested a massive amount of time in Lift over the 
past 3 years, and yes, we have prioritised features in production systems over 
the introductory experience for newbies. Personally, I think this will make us 
more mature when Lift reaches critical mass so in this way its no bad thing...

I am currently writing a 500 page book on Lift, and I hope it will fill the 
vast documentation gap that currently exists in the community. We know its a 
problem, but don't be naive enough to think that we don't know its a problem - 
the Lift team has some of the finest engineers and researchers around and a 
number of us have come from doing all manner of other frameworks and so 
forth... we understand the issues and rest assured they are being addressed.  I 
am currently collaborating with Mark @ SBT on a processor system that will give 
us a more flexible getting started system than even Rails or Django.

By all means, come here with questions and you will find this group to be very 
responsive and helpful, but do not come here and automatically assume that you 
can illuminate to us the errors in our project marketing or experience.

Cheers, Tim

PS: Who uses PDF?... easily one of the funniest things i've read this year. 
PDF is the format for electronic document communication. Hundreds of millions 
of dollars a year are spent on PDF-based technology.


On 6 Mar 2010, at 04:43, cageface wrote:

 Like many other web developers, I abandoned some heavyweight Java web
 frameworks about 6 years ago for Rails and have been working pretty
 much exclusively in Rails ever since. However, I've always had a
 secret lust for functional languages so when I heard about Scala and
 Lift I decided to take a closer look. My first impression of the
 community from studying this list and many other blogs, articles etc
 is that it's a group of smart, dedicated folks that have generously
 dedicated a lot of time and energy to making Lift a first-class
 alternative to the more conventional options.
 
 However, my first brush with the framework itself has so far left a
 very different impression. I think one of the reasons Rails caught on
 so quickly in the beginning was that it was marketed brilliantly. DHH
 made Rails look so simple, stylish and intuitive that anybody drowning
 in the bulk and complexity of Java web dev at the time couldn't help
 but take notice. Lift, in contrast, and particularly for anybody with
 a prior history in Java, seems very daunting and rough. The following
 impressions are very much superficial first impressions and may really
 have no deeper substance than that but I think first impressions count
 for a lot in this sphere.
 
 First, the liftweb.net site is nice. It's a clean, elegant,
 contemporary design. So far so good. Let's click on getting started.
 What's this? PDF? Who uses PDF? Nevermind, let's look at the HTML.
 Gack! This looks like an academic LaTEX conversion from the 90s.
 Layout and formatting are next to non-existent. This doesn't look like
 the intro for a simple, ready-to-use tool.
 
 Oh well, pushing past the wall of text intro we discover that we need
 Maven. Alarms are starting to go off in the heads of many Java
 refugees that remember Maven as the nadir of the XML-situp
 overabstracted agony that was pre-Rails Java web dev. I imagine many
 people have signed off by this point. We go download maven and press
 on to the first actual command we can run, which is an impressively
 cryptic 8-line mvn invocation that seems to take about 10 minutes to
 download every single apache and codehaus jar file.
 
 When this finally winds down we start the server and take a look at
 our homely start page and bounce back to the docs. XHTML. Hmmm. Didn't
 everybody give up on that a few years ago? HTML literals *in* the
 code? All the snippets we're going to be editing live six levels
 deep in the project directory structure? This will be fun with emacs/
 vim...
 
 By this point our enthusiasm is seriously waning but our dreams of an
 expressive but statically typed platform keep us going on to the next
 section anyway. We begin with another mvn invocation that mysteriously
 fails. After futzing with it for a bit and googling around we discover
 that there are spaces following each of the \ line continuations so we
 copy and paste the whole thing into a file, clean it up, and invoke it
 via sh. After this finishes we create the first model, which actually
 looks pretty reasonable, similar to a Django model with a little more
 boilerplate but nothing too intimidating. We discover to our chagrin

Re: [Lift] superficial first impressions from a rails junkie

2010-03-06 Thread Jeppe Nejsum Madsen

Timothy Perrett timo...@getintheloop.eu writes:

 Sorry Jeppe, but I disagree.

On which part :-) Maybe the not really into the visual
aesthetics. What I meant was not that we don't care, but more that we
will rather spend time on coding.

 The issue to date has been getting someone to work on it for
 free... The recession has worked against us here because people have
 been hand-to-mouth work wise, and couldn't spare time that wasn't paid
 for.

Look at it this way: Committers work on the code for free and I guess
that's also the case for many other OSS projects. Yet some still manage
to create visually pleasing websites  introduction material. I can only
(perhaps falsely?)  attribute this to the difference in focus/skills of
the team.

 I actually come from a marketing / design background, and have tried
 to move this aspect of Lift along, but its been problematic with
 designers not committing and so forth. Lift needs a rebrand / restyle,
 yes, however, its easier said than done.

My point exactly. If someone on the Lift community feels strong enough
about this (and has the skills) it would move forward in the same way as
the code...alas it doesn't, so we need to force it by trying to
hire/manage someone external.

/Jeppe

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: 2.0-M3 JQuery 1.4

? Did you refresh the browser to make sure that the resources is
fetched?

If you don't want to bother we resource refresh you can try this:

lift:with-resource-id

// put your script tags here

/lift:with-resource-id


I just re-tested and it is working just fine for me

JQuery14Artifacts points to JQuery 1.4.2

On 6 mar., 06:50, aw anth...@whitford.com wrote:
 I understand from Issue 363 that I can control which version of JQuery
 to use.  I generally prefer the latest and greatest, and I see that I
 am using 1.3.2, so I want to set it to 1.4.2.  According to this
 thread:
    http://groups.google.com/group/liftweb/browse_thread/thread/807a9397f...
 I thought it was as easy as adding this line to boot:
     LiftRules.jsArtifacts = JQuery14Artifacts

 Alas, this doesn't seem to work for me as I am still getting 1.3.2...

 Also, I see that Issue 311, which was closed in 2.0-M2, says that
 1.4.1 is the default.  But I don't think that was the case, right?

 Can somebody please tell me what I am missing?  This strikes me as a
 good Wiki topic.  ;-)

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: [lift] superficial first impressions from a rails junkie



Warren Henning wrote:
 
 tl;dr
 
 Want a cookie for your efforts?
 
 If you don't like Lift, don't use it. Problem solved. Hooray, turkey
 for everyone!
 
 

There are few things sillier than investing time - serious time from lots of
people - in a framework aimed at programmers and then treating detailed
feedback from programmers this way. If you are not interested in feedback
per se, then simply don't respond. If you disagree with the specifics, then
discuss politely. Otherwise you are not just devaluing your own effort but
that of other contributors by creating the impression that the community is
unfriendly and immature.

-- 
View this message in context: 
http://old.nabble.com/superficial-first-impressions-from-a-rails-junkie-tp27802055p27804300.html
Sent from the liftweb mailing list archive at Nabble.com.

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: [lift] superficial first impressions from a rails junkie

Jeppe Nejsum Madsen wrote:

Timothy Perrett timo...@getintheloop.eu writes:

Sorry Jeppe, but I disagree.

On which part :-) Maybe the not really into the visual
aesthetics. What I meant was not that we don't care, but more that we
will rather spend time on coding.

The issue to date has been getting someone to work on it for
free... The recession has worked against us here because people have
been hand-to-mouth work wise, and couldn't spare time that wasn't paid
for.

Look at it this way: Committers work on the code for free and I guess
that's also the case for many other OSS projects. Yet some still manage
to create visually pleasing websites introduction material. I can only
(perhaps falsely?) attribute this to the difference in focus/skills of
the team.

I actually come from a marketing / design background, and have tried
to move this aspect of Lift along, but its been problematic with
designers not committing and so forth. Lift needs a rebrand / restyle,
yes, however, its easier said than done.

My point exactly. If someone on the Lift community feels strong enough
about this (and has the skills) it would move forward in the same way as
the code...alas it doesn't, so we need to force it by trying to
hire/manage someone external.

/Jeppe

--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.

Rebranding Lift wouldn't be about logos. They're irrelevant to a product
aimed at programmers. You need to identify an occupy-able niche and then
communicate your advantage in that niche to the right people. That means
saying convincingly

- Lift does X better than existing solutions
- Here's why you should believe that and invest time
- Here is how to get started

And that X has to be very concrete. At the moment Lift's brand is It uses
Scala, It has a reputation for being hard, and I don't know if anyone is
really using it.

You also have to kill the potential killer negatives - eg concerns that Lift
will still be around in two or three years.

I would also say that re-branding needs to happen *fast* before attention
focuses on Grails - there is only so much new mindshare available at any
time.

--
View this message in context:
http://old.nabble.com/superficial-first-impressions-from-a-rails-junkie-tp27802055p27804368.html
Sent from the liftweb mailing list archive at Nabble.com.

[Lift] Re: Problem with FocusOnLoad and passing attributes through bind

2010-03-06 Thread Luke Nezda

Thanks for responding Marius.  You're right, my doSearch method
doesn't need the msg parameter -- that was just an artifact of
transforming an example (removed now).  As far as my specific issue, I
guess you're saying the best solution is for the framework to add
overload def -%(in: NodeSeq = NodeSeq) congruent with - -- should I
file a feature request?  As you said, Group(FocusOnLoad...) doesn't
compile either because it returns a Node, not the currently required
Element.  Did I misunderstand?  In the short term how would you solve
this ?

Thanks,
- Luke

On Mar 6, 1:39 am, Marius marius.dan...@gmail.com wrote:
 On 22 feb., 04:12, Luke  Nezda lne...@gmail.com wrote:



  Hello,

  I am new to Scala and Lift.  I am having a problem using 2 features
  together which seem to work fine individually.  Here's a simplified
  piece of the code:

  class Ajax {
    def someResult(q:String) = spansome results for query {q}.../
  span
    // searchField closure
    def searchField(xhtml: NodeSeq): NodeSeq = {
      // build up an ajax text box
      def doSearch(msg: NodeSeq) = {
        // doesn't compile with bind: searchBox -% doSearch _
        FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
  someResult(q
        // compiles with bind: searchBox -% doSearch _
        // SHtml.ajaxText(, q = SetHtml(resultz, someResult(q)))
      }
      // bind the view to the functionality
      bind(ajax, xhtml,
           searchBox - doSearch _
           // doesn't compile if doSearch returns result of FocusOnLoad
           //searchBox -% doSearch _
           )
    }

  }

  and the template invocation:

  lift:surround with=default at=content
    lift:Ajax.searchField id_msgs=messages
        ajax:searchBox class=text type=search tabindex=1 /
        hr class=space/
        div id=resultz/div
        div id=messages/div
    /lift:Ajax.searchField
  /lift:surround

  My goal is an Ajax-enabled text input that gets focus when the page
  loads and has various attributes of the input element set.  I realize
  I can use the SHtml.ajaxText variant that takes attribute-value pairs,
  as in:

    FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
  Yawni.query(q)), (class, text), (type, search), (tabindex,
  1)))

  but I'm trying to keep the various element attributes in the template.

  When I try to bind with:
    searchBox -% doSearch _
  instead of:
    searchBox - doSearch _

  I get the following compile error:

  snippet/Ajax.scala:109: error: overloaded method value -% with
  alternatives ((scala.xml.NodeSeq) =
  scala.xml.Elem)net.liftweb.util.Helpers.FuncBindParam and
  (Option[scala.xml.Elem])net.liftweb.util.Helpers.FuncBindParam and
  (net.liftweb.common.Box[scala.xml.Elem])net.liftweb.util.Helpers.FuncBindPa 
  ram
  and (scala.xml.Elem)net.liftweb.util.Helpers.FuncBindParam cannot be
  applied to ((scala.xml.NodeSeq) = scala.xml.NodeSeq)
           searchBox -% doSearch _
                       ^
  one error found

 Why your doSearch function takes a msg parameter? ... it doesn't seam
 to use it.

  doSearch _ is a partially applied function and acts as a (NodeSeq) =
 NodeSeq however -% has only a definition like:

 def -%(in: NodeSeq = Elem)

 while  - also has

 def -(in: NodeSeq = NodeSeq)

 which is why you get the compile error. We should add the same
 definition for NodeSeq = NodeSeq

 You can simply say:

  searchBox -% doSearch

 and have def doSearch: NodeSeq = ...

 FocusOnLoad returns a NodeSeq because it returns a sequence of nodes
 which conceptually cannot be converted to an elem. You could try to
 have a Group(FocusOnLoad ...) ... but Group is a Node not an Elem.



  Between all the bind() and -()/-%() overloads and my general Scala /
  Lift ignorance, I can't understand what the right way to resolve this
  is.  I think it has something to do with FocusOnLoad returning a
  NodeSeq (input/script/) vs. an Element, but I don't know where to
  go from here...

  Thanks in advance,
  - Luke

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: Problem with FocusOnLoad and passing attributes through bind

2010-03-06 Thread Luke Nezda

Thanks for responding Marius.  You're right, my doSearch method
doesn't need the msg parameter -- that was just an artifact of
transforming an example (removed now).  As far as my specific issue, I
guess you're saying the best solution is for the framework to add
overload def -%(in: NodeSeq = NodeSeq) congruent with - -- should I
file a feature request?  As you said, Group(FocusOnLoad...) doesn't
compile either because it returns a Node, not the currently required
Element.  Did I misunderstand?  In the short term how would you solve
this ?

Thanks,
- Luke

On Mar 6, 1:39 am, Marius marius.dan...@gmail.com wrote:
 On 22 feb., 04:12, Luke  Nezda lne...@gmail.com wrote:



  Hello,

  I am new to Scala and Lift.  I am having a problem using 2 features
  together which seem to work fine individually.  Here's a simplified
  piece of the code:

  class Ajax {
    def someResult(q:String) = spansome results for query {q}.../
  span
    // searchField closure
    def searchField(xhtml: NodeSeq): NodeSeq = {
      // build up an ajax text box
      def doSearch(msg: NodeSeq) = {
        // doesn't compile with bind: searchBox -% doSearch _
        FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
  someResult(q
        // compiles with bind: searchBox -% doSearch _
        // SHtml.ajaxText(, q = SetHtml(resultz, someResult(q)))
      }
      // bind the view to the functionality
      bind(ajax, xhtml,
           searchBox - doSearch _
           // doesn't compile if doSearch returns result of FocusOnLoad
           //searchBox -% doSearch _
           )
    }

  }

  and the template invocation:

  lift:surround with=default at=content
    lift:Ajax.searchField id_msgs=messages
        ajax:searchBox class=text type=search tabindex=1 /
        hr class=space/
        div id=resultz/div
        div id=messages/div
    /lift:Ajax.searchField
  /lift:surround

  My goal is an Ajax-enabled text input that gets focus when the page
  loads and has various attributes of the input element set.  I realize
  I can use the SHtml.ajaxText variant that takes attribute-value pairs,
  as in:

    FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
  Yawni.query(q)), (class, text), (type, search), (tabindex,
  1)))

  but I'm trying to keep the various element attributes in the template.

  When I try to bind with:
    searchBox -% doSearch _
  instead of:
    searchBox - doSearch _

  I get the following compile error:

  snippet/Ajax.scala:109: error: overloaded method value -% with
  alternatives ((scala.xml.NodeSeq) =
  scala.xml.Elem)net.liftweb.util.Helpers.FuncBindParam and
  (Option[scala.xml.Elem])net.liftweb.util.Helpers.FuncBindParam and
  (net.liftweb.common.Box[scala.xml.Elem])net.liftweb.util.Helpers.FuncBindPa 
  ram
  and (scala.xml.Elem)net.liftweb.util.Helpers.FuncBindParam cannot be
  applied to ((scala.xml.NodeSeq) = scala.xml.NodeSeq)
           searchBox -% doSearch _
                       ^
  one error found

 Why your doSearch function takes a msg parameter? ... it doesn't seam
 to use it.

  doSearch _ is a partially applied function and acts as a (NodeSeq) =
 NodeSeq however -% has only a definition like:

 def -%(in: NodeSeq = Elem)

 while  - also has

 def -(in: NodeSeq = NodeSeq)

 which is why you get the compile error. We should add the same
 definition for NodeSeq = NodeSeq

 You can simply say:

  searchBox -% doSearch

 and have def doSearch: NodeSeq = ...

 FocusOnLoad returns a NodeSeq because it returns a sequence of nodes
 which conceptually cannot be converted to an elem. You could try to
 have a Group(FocusOnLoad ...) ... but Group is a Node not an Elem.



  Between all the bind() and -()/-%() overloads and my general Scala /
  Lift ignorance, I can't understand what the right way to resolve this
  is.  I think it has something to do with FocusOnLoad returning a
  NodeSeq (input/script/) vs. an Element, but I don't know where to
  go from here...

  Thanks in advance,
  - Luke

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: Problem with FocusOnLoad and passing attributes through bind

In the short term you would solve it as I suggested:

Use in your bind

 searchBox -% doSearch

and define your doSearch as:

def doSearch: NodeSeq =  {
... do your stuff here
}

Actually thinking more into it there is a good reason for -% to not
have a (NodeSeq) = NodeSeq support. -% means that it preserves the
attributes specified in the template to the resulting node.But having
a bunch of attributes we can't apply them to a NodeSeq because aa
NodeSeq means a sequence of Nodes with no commn parent so we can;t
determine to which node we'd apply those attributes. AFAIK only an
Elem can have attributes.




On Mar 6, 6:45 pm, Luke  Nezda lne...@gmail.com wrote:
 Thanks for responding Marius.  You're right, my doSearch method
 doesn't need the msg parameter -- that was just an artifact of
 transforming an example (removed now).  As far as my specific issue, I
 guess you're saying the best solution is for the framework to add
 overload def -%(in: NodeSeq = NodeSeq) congruent with - -- should I
 file a feature request?  As you said, Group(FocusOnLoad...) doesn't
 compile either because it returns a Node, not the currently required
 Element.  Did I misunderstand?  

You are correct. I mainly pointed to Group just as a reminder as it
can be useful to aggregate nodes. It wont work in your case.

In the short term how would you solve
 this ?

 Thanks,
 - Luke

 On Mar 6, 1:39 am, Marius marius.dan...@gmail.com wrote:



  On 22 feb., 04:12, Luke  Nezda lne...@gmail.com wrote:

   Hello,

   I am new to Scala and Lift.  I am having a problem using 2 features
   together which seem to work fine individually.  Here's a simplified
   piece of the code:

   class Ajax {
     def someResult(q:String) = spansome results for query {q}.../
   span
     // searchField closure
     def searchField(xhtml: NodeSeq): NodeSeq = {
       // build up an ajax text box
       def doSearch(msg: NodeSeq) = {
         // doesn't compile with bind: searchBox -% doSearch _
         FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
   someResult(q
         // compiles with bind: searchBox -% doSearch _
         // SHtml.ajaxText(, q = SetHtml(resultz, someResult(q)))
       }
       // bind the view to the functionality
       bind(ajax, xhtml,
            searchBox - doSearch _
            // doesn't compile if doSearch returns result of FocusOnLoad
            //searchBox -% doSearch _
            )
     }

   }

   and the template invocation:

   lift:surround with=default at=content
     lift:Ajax.searchField id_msgs=messages
         ajax:searchBox class=text type=search tabindex=1 /
         hr class=space/
         div id=resultz/div
         div id=messages/div
     /lift:Ajax.searchField
   /lift:surround

   My goal is an Ajax-enabled text input that gets focus when the page
   loads and has various attributes of the input element set.  I realize
   I can use the SHtml.ajaxText variant that takes attribute-value pairs,
   as in:

     FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
   Yawni.query(q)), (class, text), (type, search), (tabindex,
   1)))

   but I'm trying to keep the various element attributes in the template.

   When I try to bind with:
     searchBox -% doSearch _
   instead of:
     searchBox - doSearch _

   I get the following compile error:

   snippet/Ajax.scala:109: error: overloaded method value -% with
   alternatives ((scala.xml.NodeSeq) =
   scala.xml.Elem)net.liftweb.util.Helpers.FuncBindParam and
   (Option[scala.xml.Elem])net.liftweb.util.Helpers.FuncBindParam and
   (net.liftweb.common.Box[scala.xml.Elem])net.liftweb.util.Helpers.FuncBindPa
ram
   and (scala.xml.Elem)net.liftweb.util.Helpers.FuncBindParam cannot be
   applied to ((scala.xml.NodeSeq) = scala.xml.NodeSeq)
            searchBox -% doSearch _
                        ^
   one error found

  Why your doSearch function takes a msg parameter? ... it doesn't seam
  to use it.

   doSearch _ is a partially applied function and acts as a (NodeSeq) =
  NodeSeq however -% has only a definition like:

  def -%(in: NodeSeq = Elem)

  while  - also has

  def -(in: NodeSeq = NodeSeq)

  which is why you get the compile error. We should add the same
  definition for NodeSeq = NodeSeq

  You can simply say:

   searchBox -% doSearch

  and have def doSearch: NodeSeq = ...

  FocusOnLoad returns a NodeSeq because it returns a sequence of nodes
  which conceptually cannot be converted to an elem. You could try to
  have a Group(FocusOnLoad ...) ... but Group is a Node not an Elem.

   Between all the bind() and -()/-%() overloads and my general Scala /
   Lift ignorance, I can't understand what the right way to resolve this
   is.  I think it has something to do with FocusOnLoad returning a
   NodeSeq (input/script/) vs. an Element, but I don't know where to
   go from here...

   Thanks in advance,
   - Luke

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to

[Lift] Re: [lift] superficial first impressions from a rails junkie

As this is likely to be very controversial, I'll recap one more time while my
gf finishes dying her hair -

- Don't ignore people like Mark. His feedback was detailed, thoughtful, and
invaluable if want non-committers to use Lift

- Do decide how you are going to position Lift. Position being about
-- What can Lift do better than its rivals?
-- Who should use it? Is it a master programmer's tool or accessible to the
Drupal crowd? If inbetween, where exactly?

Having done that then, rather than a new logo, I'd suggest writing a couple
of articles about Lift that centre around above (Eg Lift is *the* tool for
intermediate experienced Java programmers who need to deploy high
performance sites that do X) and creating a new and thoroughly debugged new
user guide. Get new users, sit them in front of a PC and watch what happens.
Do not help them. Do make notes on what they do and say - and fix every
problem that comes out this way. (I'd probably be willing to work on these
things, although I expect the sentiment for lynching me will be stronger.)

--
View this message in context:
http://old.nabble.com/superficial-first-impressions-from-a-rails-junkie-tp27802055p27805716.html
Sent from the liftweb mailing list archive at Nabble.com.

[Lift] Re: [lift] superficial first impressions from a rails junkie

Timothy Perrett wrote:

By all means, come here with questions and you will find this group to be
very responsive and helpful, but do not come here and automatically assume
that you can illuminate to us the errors in our project marketing or
experience.

What's automatic about Mark's analysis? He's a new Lift user, he's told you
what the new user experience is like - he did the appropriate work to be
able to do this. If there is anything automatic here it is your dismissal of
the problems that Mark had. This sort of user feedback is gold - he's made a
real effort to tell you what trying to get started with Lift was like for
him. And reading what Mark wrote, I'm sure that he is much brighter and more
interested in Lift than the average Java/RoR programmer.

Lift is not Rails. It really bugs me when people are like oh, well rails
does XYZ.

The guy never said it was. He explained why he switched to Rails and why he
thinks Rails has been successful.

The important point that Rails people who want their framework to takeoff
have to understand here is ***that at no time during Mark's experience did
anyone communicate a reason to him why Lift was worth persevering with.***
That's what marketing is about. If Mark had known there was a strong enough
potential benefit then he would have persisted. At the moment Lift's only
perceived benefit seems to be that it provides you with a web framework for
Scala. That's a nice strategy for getting a couple of dozen FPophiles to
commit code, but it won't take Lift anywhere in the real world of What does
this framework do for my project/career/business.

You need to start telling people what Lift especially well so that they have
some idea why they might use it! The best effort I have seen to do this
comes not from the Lift community but from another reviewer, here -

http://ikaisays.com/2009/03/03/first-impressions-of-lift-scala-web-development-framework-from-a-ruby-on-rails-developer/

Other concerns:

- I suspect that Lift has enough mass inside the Scala community to prevent
the emergence of another web framework. And that without an acceptable web
framework Scala - which I am now 100% in love with - will not be a
successful language.

- How much of the difficulty that people seem to have in using Lift is
intrinsic to the framework and how much to poor docs? What are the
***pay-offs*** for those design decisions that have made Lift harder to use?
(Even when this simply means less Rails-like.) Communicating these would go
a long way to reducing newbie frustration. Is Lift even designed to have as
wide an appeal as RoR or Grails? If not, be frank about it and communicate
where its strengths lie.

--
View this message in context:
http://old.nabble.com/superficial-first-impressions-from-a-rails-junkie-tp27802055p27805572.html
Sent from the liftweb mailing list archive at Nabble.com.

[Lift] Re: superficial first impressions from a rails junkie

2010-03-06 Thread ngocdaothanh

 It intentionally avoids putting code in the template. This keeps the template 
 clean... Putting code inside the template is one of the worse design 
 decisions ever. Putting template fragments inside Scala code makes tremendous 
 sense as it allows a truly flexible way of achieving compositionality, 
 reusability etc.

I think Lift does not win anything over Rails at this point. In Rails,
putting code inside template is also a really very bad practice.
That's why Rails has app/helpers directory, code should be put in
helpers and refactored there.

What I mean is when advertising Lift over Rails, this should not be
insisted much, e.g. saying Rails puts code inside the template, or
experienced Rails developers would think Lift developers don't know
Rails enough.

Instead of that, I think one of Lift features that is absolutely a big
win is seamless request-response cycle. One consequence is that it
makes building Ajax/Comet application very easy.

Nitrogen framework also has this feature. That's why I put the link to
its home page, with the hope that Lift committers would glance its
implementation. Maybe there's something there they may learn from, I
don't know.

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: 2.0-M3 SLF4J Logging

2010-03-06 Thread aw

Thanks Jeppe.  I definitely like this new logging stuff.  I updated
the wiki.

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] superficial first impressions from a rails junkie

Thanks for your comments.

I did Ruby/Rails for 2 years until I found Scala in November 2006.

Please allow me to rebut your thoughtful post.

On Fri, Mar 5, 2010 at 8:43 PM, cageface milese...@gmail.com wrote:

 Like many other web developers, I abandoned some heavyweight Java web
 frameworks about 6 years ago for Rails and have been working pretty
 much exclusively in Rails ever since.


Back when I was doing Rails, the state of Rails' documentation was not
materially different from the current state of Lift's documentation with the
exception of DHH's awesome book (which is my all time favorite tech book).
Most of the online documentation was weak or non-existent.  It was never
possible to figure out what mixins impacted the behavior of a class.  I
spent most of my time reading Rail's source to figure out how to do anything
that marginally off the beaten path.



 However, I've always had a
 secret lust for functional languages so when I heard about Scala and
 Lift I decided to take a closer look. My first impression of the
 community from studying this list and many other blogs, articles etc
 is that it's a group of smart, dedicated folks that have generously
 dedicated a lot of time and energy to making Lift a first-class
 alternative to the more conventional options.

 However, my first brush with the framework itself has so far left a
 very different impression. I think one of the reasons Rails caught on
 so quickly in the beginning was that it was marketed brilliantly.


This is one of the things I wanted to do differently with Lift.  I didn't
want to market it.  I wanted to build solid technology that addressed
serious needs including security, highly interactive apps, and scalability.
I also wanted to create a welcoming community (Warren does not represent
this community except for his brains which were missing last night when he
wrote his snarky response) so that the adoption of Lift would come from
substance, not a pile of fanboys (this is not a reference to you) who were
not able to see past the flaws in Rails.


 DHH
 made Rails look so simple, stylish and intuitive that anybody drowning
 in the bulk and complexity of Java web dev at the time couldn't help
 but take notice. Lift, in contrast, and particularly for anybody with
 a prior history in Java, seems very daunting and rough.


It depends on what you want to do.

One of the problems I found with new Rails apps was that they were ugly and
unstyled.  We adopted Blueprint CSS as a default for Lift projects so at
least they looked clean.  Further, Lift's templating with surround makes
it much easier to swap out better looking sites.  My experience doing Rails
(remember, this goes back 5 years, so this situation may have changed) was
that I spent the first hour of any project doing the layout.

The second issue with Rails apps is when you do them easy they tend not to
be secure.  When I say secure, I mean this kind of secure:
http://twitter.com/rasmus/status/5929904263 When you protoype in Lift, you
get secure by default.  You don't have to have the security sprint or
other stuff after prototype stage to get things right.


 The following
 impressions are very much superficial first impressions and may really
 have no deeper substance than that but I think first impressions count
 for a lot in this sphere.


While I agree, that early impressions are important. But at the same time,
Lift is unabashedly different.  It's different for reasons and those reasons
are often borne out of experience.  It takes some time to get used to the
differences.

My goal with the getting started guide was to set up ET-style Reese's Pieces
so that the reader would get a sense of success and a sense of Lift's
difference and benefits.  I'm sorry that the pieces didn't taste good to
you. ;-)



 First, the liftweb.net site is nice. It's a clean, elegant,
 contemporary design. So far so good. Let's click on getting started.
 What's this? PDF? Who uses PDF?


While I'm not sure I 100% agree with Tim's 6 million dollar man argument
about PDF, PDF is common and useful... Scribd (which is definitely in the
hip-cool-kids side of street) is built on PDF.


 Nevermind, let's look at the HTML.
 Gack! This looks like an academic LaTEX conversion from the 90s.
 Layout and formatting are next to non-existent. This doesn't look like
 the intro for a simple, ready-to-use tool.


Okay... sorry... but this is a gratuitous swipe.  Ugly == Not Easy to Use.
Nope.  Sorry.  I don't buy this.



 Oh well, pushing past the wall of text intro we discover that we need
 Maven. Alarms are starting to go off in the heads of many Java
 refugees that remember Maven as the nadir of the XML-situp
 overabstracted agony that was pre-Rails Java web dev.


We are not in the build tool business.  When we started with Lift, the
options were Ant and Maven.  You can read this list for the occasional
anti-Maven flare-up.  I stand by the decision.

Currently, there are a couple of alternatives to Maven.

Re: [Lift] superficial first impressions from a rails junkie

On Fri, Mar 5, 2010 at 9:58 PM, Warren Henning warren.henn...@gmail.comwrote:

 tl;dr

 Want a cookie for your efforts?

 If you don't like Lift, don't use it. Problem solved. Hooray, turkey
 for everyone!


Warren -- this comment is way out of bounds for the Lift list.  You know I
love your sarcasm and your grumpy-as-an-80-year-old-at-21 attitude, but
dude... somewhere else please.



 --
 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.




-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: superficial first impressions from a rails junkie

A few notes from my behalf. I understand Tim's perspective and I fully
agree with, but this is a perspective of a guy coming from Lift side
which is likely to differ from the perspective of a new comer.

1. I definitely do not agree with something like here is why you
should use A and not B thus you need to persevere with A ... this
sounds like an american anti-commercial for detergents (no offense US
folks). Where you believe it or not we do value the good things of
other frameworks and learn from their mistakes.

2. Even if Lift docs are way behind I still think that there is truly
enough material out there to convince people of its value or help them
make a decision whether to adopt it or not. There are hundreds of
people using Lift and quite a handful of corporates (SAS, Novell,
Twitter, Xerox, ... Tim and Dave have a wider list)

3. You say ... for those design decisions that have made Lift harder
to use  what design decisions? I'm quite aware about lift's
design and guts and I'm not aware of any of design decisions that made
Lift harder to use. There is a fundamental difference between
understanding the design and just say or allude that Lift is hard to
use by design.

4. Yes I agree that Lift has a powerful contribution to Scala adoption
but in reality I think it is a mutual thing.

5. How much of the difficulty that people seem to have in using Lift
is intrinsic to the framework and how much to poor docs? good
question but hard to tell. People come with different mindsets and
backgrounds. For some it is hard to accept View-First as they seem to
have a too strong MVC mind set. Some are just open minded (most of
people on this list I'd add) and this people came with concrete cases
and I truly believe that Lift team helped them quite a bit.

6. Lift strengths were communicated by this list, by talks done by
David, Tim, Derek myself etc., By the Definitive guide to Lift book,
numerous blog posts etc. numerous examples, .. if you checkout Lift
you'll get a list of example apps that demonstrates it power. So I
resent this argument.

7. I don't know what you are refer to appeal when you are talking
about Lift. Is it about visual design of site, docs etc ? If not
please define appeal in this context? .. I tend to thing that this is
a subjective term in many respects.


On Mar 6, 7:02 pm, jonathan mawson umpti...@gmail.com wrote:
 Timothy Perrett wrote:

  By all means, come here with questions and you will find this group to be
  very responsive and helpful, but do not come here and automatically assume
  that you can illuminate to us the errors in our project marketing or
  experience.

 What's automatic about Mark's analysis? He's a new Lift user, he's told you
 what the new user experience is like - he did the appropriate work to be
 able to do this. If there is anything automatic here it is your dismissal of
 the problems that Mark had. This sort of user feedback is gold - he's made a
 real effort to tell you what trying to get started with Lift was like for
 him. And reading what Mark wrote, I'm sure that he is much brighter and more
 interested in Lift than the average Java/RoR programmer.

  Lift is not Rails. It really bugs me when people are like oh, well rails
 does XYZ.

 The guy never said it was. He explained why he switched to Rails and why he
 thinks Rails has been successful.

 The important point that Rails people who want their framework to takeoff
 have to understand here is ***that at no time during Mark's experience did
 anyone communicate a reason to him why Lift was worth persevering with.***
 That's what marketing is about. If Mark had known there was a strong enough
 potential benefit then he would have persisted. At the moment Lift's only
 perceived benefit seems to be that it provides you with a web framework for
 Scala. That's a nice strategy for getting a couple of dozen FPophiles to
 commit code, but it won't take Lift anywhere in the real world of What does
 this framework do for my project/career/business.

 You need to start telling people what Lift especially well so that they have
 some idea why they might use it! The best effort I have seen to do this
 comes not from the Lift community but from another reviewer, here -

 http://ikaisays.com/2009/03/03/first-impressions-of-lift-scala-web-de...

 Other concerns:

 - I suspect that Lift has enough mass inside the Scala community to prevent
 the emergence of another web framework. And that without an acceptable web
 framework Scala - which I am now 100% in love with - will not be a
 successful language.

 - How much of the difficulty that people seem to have in using Lift is
 intrinsic to the framework and how much to poor docs? What are the
 ***pay-offs*** for those design decisions that have made Lift harder to use?
 (Even when this simply means less Rails-like.) Communicating these would go
 a long way to reducing newbie frustration. Is Lift even designed to have as
 wide an appeal as RoR or Grails? If not, be frank

[Lift] Re: [lift] superficial first impressions from a rails junkie

Re. branding == What can you do for me, just compare the sites from Grails
and Lift.

Grails:

Have your next Web 2.0 project done in weeks instead of months. Grails
delivers a new age of Java web application productivity.
- Ok, this is (claimed to be) a high productivity Web 2.0 framework.

Get instant feedback, see instant results. Grails is the premier dynamic
language web framework for the JVM.
- So appeals to agile/TDDers. And no one is ever fired for choosing the JVM.

This is pretty good - if you're a Java guy looking to stay with the platform
and get RoR productivity, or a RoR guy looking for more performance, either
way you'll stay to here more and maybe do a google search to see what other
people say.

Lift:

Lift is the only new framework in the last four years to offer fresh and
innovative approaches to web development. It's not just some incremental
improvements over the status quo, it redefines the state of the art. If you
are a web developer, you should learn Lift. Even if you don't wind up using
it everyday, it will change the way you approach web applications.

- This is great to have on a CV. But as marketing material it is dismal.
Yes, the designer of Lift must be smart - but what problem does Lift solve
for me? And redefines the state of the art sounds like a lot to learn
and Even if you don't wind up using it everyday sounds like you WON'T end
up using it.

Lift is an expressive and elegant framework for writing web applications.
Lift stresses the importance of security, maintainability, scalability and
performance, while allowing for high levels of developer productivity

- If you throw much stuff at people at once they retain nothing. There is no
focus. Especially when the claims are vague (expressive) and
all-embracing.

Lift borrows from the best of existing frameworks, providing

Seaside's highly granular sessions and security
Rails fast flash-to-bang
Django's more than just CRUD is included
Wicket's designer-friendly templating style (see Lift View First)

- This is too easily read as Lift is very complicated. And We are
technology obsessed rather than business problem focussed. So there go most
programmers and virtually all their managers.

(Btw - no one who wants to write highly granular anything should be
allowed near the first page of a website for anything. Except possibly sand.
Highly granular is NOT a benefit; a definite claim about the level of
security provided and the credibility of the same would be.)

The Grails site does everything right. It tells the reader if he is one of
the people Grails is designed for, reassuring him that it is reasonable for
him to invest more time. It tells him what Grails is good for, and it
reduces his perception of risk. Time is money for developers; wasted time is
wasted money - not just billable hours gone, but time that could have been
invested in something that will keep them employed. But the promised
benefit - RoR productvity, Java performance - is even more important than
the reassurance about the cost. At the moment the Lift site doesn't promise
anything at all - and it inadvertently hints at a very high cost.

Buit I have heard worse - there's the story of a Xerox Parc guy who was
asked whether the problem was that Xerox's marketing people tried to sell
the steak instead of the sizzle. The steak? he asked, incredulously. If
you'd given our guys steaks to sell they'd have advertised 'Electrically
heated two week old dead meat..'
--
View this message in context:
http://old.nabble.com/superficial-first-impressions-from-a-rails-junkie-tp27802055p27805956.html
Sent from the liftweb mailing list archive at Nabble.com.

Re: [Lift] Re: [lift] superficial first impressions from a rails junkie

On Sat, Mar 6, 2010 at 9:02 AM, jonathan mawson umpti...@gmail.com wrote:

Timothy Perrett wrote:

By all means, come here with questions and you will find this group to be
very responsive and helpful, but do not come here and automatically
assume
that you can illuminate to us the errors in our project marketing or
experience.

What's automatic about Mark's analysis? He's a new Lift user, he's told you
what the new user experience is like - he did the appropriate work to be
able to do this. If there is anything automatic here it is your dismissal
of
the problems that Mark had. This sort of user feedback is gold - he's made
a
real effort to tell you what trying to get started with Lift was like for
him. And reading what Mark wrote, I'm sure that he is much brighter and
more
interested in Lift than the average Java/RoR programmer.

Lift is not Rails. It really bugs me when people are like oh, well rails
does XYZ.

The guy never said it was. He explained why he switched to Rails and why he
thinks Rails has been successful.

The important point that Rails people who want their framework to takeoff
have to understand here is ***that at no time during Mark's experience did
anyone communicate a reason to him why Lift was worth persevering with.***
That's what marketing is about. If Mark had known there was a strong enough
potential benefit then he would have persisted. At the moment Lift's only
perceived benefit seems to be that it provides you with a web framework for
Scala. That's a nice strategy for getting a couple of dozen FPophiles to
commit code, but it won't take Lift anywhere in the real world of What
does
this framework do for my project/career/business.

You need to start telling people what Lift especially well so that they
have
some idea why they might use it! The best effort I have seen to do this
comes not from the Lift community but from another reviewer, here -

http://ikaisays.com/2009/03/03/first-impressions-of-lift-scala-web-development-framework-from-a-ruby-on-rails-developer/

Other concerns:

You mistake different with harder. People who are used to one way to do
things will find different harder than the same.

In the case of view-first, there are plenty of posts as to why it's better.

In the case of Maven, there are plenty of posts and discussions on that
matter as well.

More broadly, and I wish I had pointed this out to the OP, Lift projects are
typically smaller than similar Rails projects. The couple of ports I've
done, I've seen some substantive code reductions and significant test code
reductions. And, what I've gotten in addition to a smaller code base is
higher performance, more security, and more maintainability. So, Lift is in
fact not harder to use.

(Even when this simply means less Rails-like.) Communicating these would go
a long way to reducing newbie frustration. Is Lift even designed to have as
wide an appeal as RoR or Grails? If not, be frank about it and communicate
where its strengths lie.

--
View this message in context:
http://old.nabble.com/superficial-first-impressions-from-a-rails-junkie-tp27802055p27805572.html
Sent from the liftweb mailing list archive at Nabble.com.

--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

Re: [Lift] Re: [lift] superficial first impressions from a rails junkie

On Sat, Mar 6, 2010 at 9:19 AM, jonathan mawson umpti...@gmail.com wrote:

As this is likely to be very controversial, I'll recap one more time while
my
gf finishes dying her hair -

- Don't ignore people like Mark. His feedback was detailed, thoughtful, and
invaluable if want non-committers to use Lift

There are articles in the pipeline.

and creating a new and thoroughly debugged new
user guide.

And where are the bugs in the existing user guide? Further, the complaint
of the OP seem to be the formatting is ugly (okay, we can address this),
I don't like Maven (this will change) I don't like markup in my code,
except I do this implicitly in Rails (yeah... not much to talk about).

Get new users, sit them in front of a PC and watch what happens.
Do not help them. Do make notes on what they do and say - and fix every
problem that comes out this way. (I'd probably be willing to work on these
things, although I expect the sentiment for lynching me will be stronger.)

--
View this message in context:
http://old.nabble.com/superficial-first-impressions-from-a-rails-junkie-tp27802055p27805716.html
Sent from the liftweb mailing list archive at Nabble.com.

--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

Re: [Lift] Re: [lift] superficial first impressions from a rails junkie

On Sat, Mar 6, 2010 at 5:50 AM, jonathan mawson umpti...@gmail.com wrote:

Jeppe Nejsum Madsen wrote:

Timothy Perrett timo...@getintheloop.eu writes:

Sorry Jeppe, but I disagree.

On which part :-) Maybe the not really into the visual
aesthetics. What I meant was not that we don't care, but more that we
will rather spend time on coding.

/Jeppe

--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.

- Lift does X better than existing solutions
- Here's why you should believe that and invest time
- Here is how to get started

And that X has to be very concrete.

You mean:

Lift stresses the importance of security, maintainability, scalability and
performance, while allowing for high levels of developer productivity.

At the moment Lift's brand is It uses
Scala, It has a reputation for being hard, and I don't know if anyone
is
really using it.

You also have to kill the potential killer negatives - eg concerns that
Lift
will still be around in two or three years.

This is more of a concern about Scala in general. Every available metric
points to the fact that Lift has reached critical mass. Our community is
larger than Wicket's. Our code velocity is faster than Wicket's. Etc.

The bigger issue that I've heard from the corporate adoption side is will
Scala be around in 2 years?

I would also say that re-branding needs to happen *fast* before attention
focuses on Grails - there is only so much new mindshare available at any
time.

Every Grails vs. Lift bake-off I've been involved, Lift has won hands down.
Once you do Ajax or Comet, Lift wins. Once you try to scale, Lift wins.
More generally, ever Java shop that's adopted Groovy and then Scala has
dumped Groovy.

The advantage that Groovy/Grails has is SpringSource/VMWare. But actual
adoption is waning (just look at Tiobe).

There will be an answer to the corporate types looking for support on Lift
and Scala in the next few weeks.

--
View this message in context:
http://old.nabble.com/superficial-first-impressions-from-a-rails-junkie-tp27802055p27804368.html
Sent from the liftweb mailing list archive at Nabble.com.

--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

[Lift] Lift-M2 One To Many and CRUDify

2010-03-06 Thread ojonam

Hello all,

I recently tested the wiki example of Book and Authors as an exercise,
and extended them with CRUDify. On generation, however, the Author
field in the Book create page says : Can't Change!, instead of
giving me a select list of all the authors.

My question is : Is this normal behavior ? If not, how do I go
repairing this ?

Cheers,
Manohar

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: superficial first impressions from a rails junkie

2010-03-06 Thread Stuart Roebuck

Thank you for writing your comments.  As most have said in the thread,
honest feedback is valuable if not essential and often hard to come
by, so please don't be put off by the odd negative response.

I'm fairly newbie here too and share some of your concerns about
Lift.  For what it's worth I thought I'd share my thoughts to add to
the melting pot…

I'm an ex-Java coder who ran a business using Apache Cocoon in it's
early days.  As an agile advocate I got frustrated with Java and had a
flirted with Grails (Groovy on Rails) for one commercial project.  But
whilst I liked Groovy's conciseness I found it's loose typing and
runtime 'magic' forced undue emphasis on writing test after test.

Then I discovered Scala and fell in love!  It's a really nice language
with an amazing blend of conciseness, consistency and power.

So, when I found Lift and read around it I felt that Lift was a next
generation web framework built on the type safe solid functional Scala
language, the speed of the JVM and it's mature libraries and with
inherent and designed features that would lend itself to scalability
in the new world of cloud computing.  I checked out the community and
it looked strong and high on common sense and expertise.  Finally I
checked out it's users and found some big organisations using it
already.

So in comment to others, Lift had a good image for me, it was trying
to get started using it that was my biggest hurdle and I share much of
what Miles said about this.  The Exploring Lift PDF book is
essential but certainly wasn't easy to find at first—I see it's linked
from the front page now which I don't think it was when I started.
The new wiki pages are starting to be a really useful source of info
though it's a shame GitHub's wiki mechanism is so flat-file!  If I was
to make one criticism of the Exploring Lift book is that the example
code tends to be unnecessarily complicated to demonstrate the
particular thing that is being explained.  One of the biggest problems
I had in the early days of not knowing Scala was trying to understand
what the missing code, substituted by ... in the code listings would
have been.  Indeed in the really early days I was trying to figure out
what ... did in Scala—which isn't as stupid as it sounds!

I have been a bit disappointed with the level of commenting in the
major objects and methods of the framework.  When I can't find any
documentation I often go back to the source code and I sometimes find
either no comments or comments that are out of date with parameter
names not matching the actual parameters of the methods.  I offered to
help but found that contributing isn't as easy as it should be.

Increasingly I feel that one of the problems with Scala and Lift is
that the power and beauty of the language and framework are sometimes
lost in code that has lost restraint.  I think Lift would benefit
from:

  *  Tidier code - laid out and structured with concern given to
making it easy to follow.  Just because Scala can do it in one line
doesn't mean that four lines wouldn't be better.  Just because you can
put multiple classes and objects in a single scala file doesn't mean
it's bad to break code up into separate files.
  *  Fewer public functions, function variants and implicits.  Almost
everything in Lift seems to be public and there seems to be a love of
creating every possible variant of a function rather than letting the
user do the odd extra step themselves.  Finally, implicits get
everywhere, and implicit conversions are basically unexplained magic
to someone trying to make sense of unfamiliar code.  It's not a bad
thing to explicitly convert something—it helps to explain to you and
others what you are trying to do.

Okay, better leave it there!

I'm currently using SBT rather than Maven which is really nice to use
but currently underdocumented.  Have grown to dislike Maven against
all my attempts to like it.

All in all Lift is really powerful, I'm using it, and I would really
like it to succeed, but, like Scala, it currently lacks some marketing
flare and is succeeding by it's brilliance alone.  For those familiar
with Crossing the Chasm, I'd surmise that most Lift users are
Technology enthusiasts and the market won't grow until Lift becomes
attractive to the Visionaries who basically need some documentation!

Stuart.

On Mar 6, 4:43 am, cageface milese...@gmail.com wrote:
 Like many other web developers, I abandoned some heavyweight Java web

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: superficial first impressions from a rails junkie

2010-03-06 Thread aw

I'm overall very impressed by the community response so far to this
post.  My first reaction to this was, please don't dismiss it (like
the first response seemed to).

Marius was quick to agree that the web site needs some work.  I have
to agree here.  I am surprised by a few things:
1.  So much activity, yet liftweb.net homepage is highly static.
There is no mention, for example, of the 2.0-M3 release, progress, new
features, etc.  A newbie really needs to dig into the Google Group and
source code, but the home page should be pulling you in.  I have
repeatedly complained that I can't seem to get aggregated scaladocs
for 2.0-M3 as easy as 1.0.  Why is the first impression for a newbie
so stale?
2.  The home page doesn't display correctly on IE.  It needs to (and
I'm sure this is an easy fix).  It may give an impression that Lift
itself is so cutting edge that you need Firefox or Chrome or something
-- but that is NOT the case.  IE is still (unfortunately) dominant
among businesses, and still has a decent market share, so it should
not be ignored.
3.  There are some real live solutions using Lift (like
foursquare.com), and the home page should point that out!  It helps
add credibility.  (The Novell Pulse demo was truly inspiring.)

A little while ago, someone was asking about a Lift project idea, and
I had recommended a Lift based CMS.  My thinking was that the lift
site itself could use it.  I love it when people eat their own dog
food -- it helps me buy into the solution.

On Mar 6, 9:02 am, jonathan mawson umpti...@gmail.com wrote:
 - How much of the difficulty that people seem to have in using Lift is
 intrinsic to the framework and how much to poor docs? What are the
 ***pay-offs*** for those design decisions that have made Lift harder to use?
 (Even when this simply means less Rails-like.) Communicating these would go
 a long way to reducing newbie frustration. Is Lift even designed to have as
 wide an appeal as RoR or Grails? If not, be frank about it and communicate
 where its strengths lie.

Documentation is a challenge:
 - Scala docs have been getting better, but overall they are still
pretty sparse.  I find myself requiring to read the scala code as the
docs are insufficient.  Certainly, this can be frustrating to a newbie
(though I do agree that it helps me learn Scala and Lift better).
 - The Wiki could be improved, and extended.  Is GitHub really the
best platform?  (I am a Confluence fan.)  Much like how GitHub was
ditched for Issue Tracking, I think some thought needs to be done
about the wiki platform.
 - White Papers don't really exist that explain the benefits of Lift's
features...  Topics that security, dependency injection,
optimizations, configuration management, etc. should be covered.
(Wiki might be a good storage and content management platform for this
information.)  A comparative analysis would be great:  solution in
Groovy/Grails vs. Scala/Lift vs. Ruby/Rails vs. Java/GWT vs. Java/Flex
vs. ColdFusion.  Many struggle with choosing a web framework, and the
Lift site should be explaining why they should choose Lift.
 - The Lift Book is already out of date, and it needs to grow.  For
some reason, it is sticking to 1.0 compliance, but so much has
changed.  This was my first serious introduction to the framework, and
this needs to be maintained in line with all the cool new features
that are being added.

Yesterday, I decided to upgrade my project from 2.0-M2 to 2.0-M3 and
take advantage of the new features.  In the 2.0-M3 announcement, it
really only had release notes -- there wasn't an explanation of how to
really use these new features.  Where is this information?  It should
be going to the Lift Book, but instead I had to triangulate the
information from searching the Google Group, reviewing Source Code,
and reviewing the Issue Tracker.  This definitely could be easier.

At the end of the day, Lift is a solid framework.  The attention to
stability is very impressive.  The attitude and activity from the
community is first rate.  I still question some aspects (like View
First, or when I would ever use a view), but I am still learning and
I think that Lift is still growing.

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: Converting a rails application to lift

2010-03-06 Thread Achint Sandhu

Hi,

I've run into a slight snag with my use of the current approach. I
suspect what I'm trying to do is silly. The interaction below is from
the lift console and I don't actually use open_! in my code.

---
scala val b = Book.find(1).open_!
l: com..Book = com..Book={id=1,author=1}

scala b.author
res3: b.author.type = 1

scala b.author == 1
res4: Boolean = true
---

If for some reason a Book does not have an author (possible in my
applications case), b.author would return NULL and comparing b.author
== 1 returns Boolean = false

This approach works in the actual application, but the compiler
generates the following warning.

---
warning: comparing values of types Long and object b.author using `=='
will always yield false
---

In the specific application case I have, I have access to the
Author.id and want to check if the book is referring to the author
whose ID I have before I do something. I know that I could look up the
Author object and do the comparison, but the above seemed to be a
useful shortcut.

Is there a recommended (succinct) way of accomplishing the above ?

I'd like the thank everyone for the patience and help provided so far.

Cheers,
Achint

On Mar 2, 3:26 pm, Mads Hartmann Jensen mads...@gmail.com wrote:
 On 02/03/2010, at 20.56, Achint Sandhu wrote:





  Hi,

     I'm new to scala (2.7.7) and lift (2.0-M2) and as a learning exercise
  have taken on the translation of an existing rails project into a lift
  application.

     There are two things I have run into that I'm hoping the more
  experienced members of the list can give me a hand with:

  1) Is there a trait in lift that creates and manages an equivalent of
  the createdAt and updatedAt fields that rails provides? I'm thinking
  something along the lines of IdPK, but have been unable to find
  anything.

  2) I've been following the wiki article on setting up One-to-Many
  relationships (http://wiki.github.com/dpp/liftweb/how-to-work-with-one-
  to-many-relationships) and am running into a difference in behaviour.
  Following the example, if I look at anAuthor.books, I get back a List
  of Book objects, however when I look at aBook.author, I get back a
  Long with the ID of the Author. I would expect aBook.author to return
  an Author object. I've copied and pasted the example in the wiki, to
  make sure that it wasn't my implementation.

 You should be able to get the object by calling aBook.author.obj - this 
 should return a Box[Author] so you could get it like this

 aBook.author.obj match {
   case Full(a) = a // do something with the autor
   case Empty = // if the box is empty, handle it somehow
   case _ =  // should cover everyhting else, Failure etc

 }

 Hope it helps



     Other than that, so far, it's gone extremely well and I was able to
  get something up and running very quickly which really is a testament
  to the design of the framework.

     Thanks.

  Cheers,
  Achint

  --
  You received this message because you are subscribed to the Google Groups 
  Lift group.
  To post to this group, send email to lift...@googlegroups.com.
  To unsubscribe from this group, send email to 
  liftweb+unsubscr...@googlegroups.com.
  For more options, visit this group 
  athttp://groups.google.com/group/liftweb?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: Javascript Dependencies

2010-03-06 Thread Peter Robinett

Hi guys,

Sorry I'm only coming back to this discussion now. I think what you're
both proposing are the two parts of what should be the complete use-
case. Yes, dependencies _exist_ per page and, yes, you want to
_declare_ them per snippet or CometActor. The last (and only) commit
on my pr1001_issue_branch shows my first stab at managing and
registering the dependencies: 
http://github.com/dpp/liftweb/tree/pr1001_issue_281.
I think it is quite similar to what has been mentioned (compare
JsScript to Marius' JsDependenciesTree, ignoring that his is more
elegant =).

I think my resolve and satisfied_? methods work correctly, though they
still need someone with some CS knowledge to check them (for instance,
I'm not doing any checks for circular dependencies right now). The
only real question is _when_ to call them and how to act upon them. I
was thinking at the snippet level, not the page level. Anything
outputting (X)HTML to the browser needs to be able to register their
dependencies (CometActors by their nature should really only do it in
their initial render) for a page-wide set of dependencies which are
then resolved and merged into the head of the HTML document when the
page is finally rendered.

So, what if we have something like req.registerDependency(myJsScript)?
The Request would store the dependencies that the LiftResponse would
then take, resolve, and merge into the XHTML it's outputting. However,
CometActors exist outside of normal requests. How do we get around
this? CometActors are created initially in a Request, so we should be
able to connect then but I don't know that part of Lift well enough to
say how.

Jeppe, Marius, what do you think? Am I on the right track? Do my
suggestions address both of your concerns?

Peter

On Mar 1, 7:17 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
 Marius marius.dan...@gmail.com writes:
  Yes we do have different perspectives. I'm saying for page X here
  these are the JS dependencies whether you seem to say here is a
  snippet, and it needs these dependencies

 Yes

  I'd still prefer my paradigm (not because of my ego) because it'd be
  easier to manage redundancies, it applies generically for snippets,
  comet actors etc. without having to induce other type of API. It is
  maybe coarse grained vs. your proposal that seems to me finner
  grained.

 I think the two can co-exist, although I haven't thought it through wrt
 comet actors etc. That was what I was hinting at in the previous
 mail. At the of the day (or before sending a response at least :-) a
 page needs to have a well-defined list of script files to include.

 So it makes sense to start with your paradigm and my paradigm should
 be able to be layered on top if one wishes...

  However I'd be happy to see an implementation of any of these
  proposals. Maybe other people would have better ideas so perhaps Peter
  and/oryou could dig could make this happen?

 I'll let Peter take the lead and help where ever I can :-)

 /Jeppe

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: Converting a rails application to lift

2010-03-06 Thread Achint Sandhu

Hi,

Small update.

Changing the order of the comparison in my code

i.e. b.author == 1 instead of 1 == b.author

fixed the warning, but I'm still curious as to whether what I'm doing
is a good idea.

Thanks.

Cheers,
Achint

On Mar 6, 2:14 pm, Achint Sandhu achint.san...@gmail.com wrote:
 Hi,

 I've run into a slight snag with my use of the current approach. I
 suspect what I'm trying to do is silly. The interaction below is from
 the lift console and I don't actually use open_! in my code.

 ---
 scala val b = Book.find(1).open_!
 l: com..Book = com..Book={id=1,author=1}

 scala b.author
 res3: b.author.type = 1

 scala b.author == 1
 res4: Boolean = true
 ---

 If for some reason a Book does not have an author (possible in my
 applications case), b.author would return NULL and comparing b.author
 == 1 returns Boolean = false

 This approach works in the actual application, but the compiler
 generates the following warning.

 ---
 warning: comparing values of types Long and object b.author using `=='
 will always yield false
 ---

 In the specific application case I have, I have access to the
 Author.id and want to check if the book is referring to the author
 whose ID I have before I do something. I know that I could look up the
 Author object and do the comparison, but the above seemed to be a
 useful shortcut.

 Is there a recommended (succinct) way of accomplishing the above ?

 I'd like the thank everyone for the patience and help provided so far.

 Cheers,
 Achint

 On Mar 2, 3:26 pm, Mads Hartmann Jensen mads...@gmail.com wrote:



  On 02/03/2010, at 20.56, Achint Sandhu wrote:

   Hi,

      I'm new to scala (2.7.7) and lift (2.0-M2) and as a learning exercise
   have taken on the translation of an existing rails project into a lift
   application.

      There are two things I have run into that I'm hoping the more
   experienced members of the list can give me a hand with:

   1) Is there a trait in lift that creates and manages an equivalent of
   the createdAt and updatedAt fields that rails provides? I'm thinking
   something along the lines of IdPK, but have been unable to find
   anything.

   2) I've been following the wiki article on setting up One-to-Many
   relationships (http://wiki.github.com/dpp/liftweb/how-to-work-with-one-
   to-many-relationships) and am running into a difference in behaviour.
   Following the example, if I look at anAuthor.books, I get back a List
   of Book objects, however when I look at aBook.author, I get back a
   Long with the ID of the Author. I would expect aBook.author to return
   an Author object. I've copied and pasted the example in the wiki, to
   make sure that it wasn't my implementation.

  You should be able to get the object by calling aBook.author.obj - this 
  should return a Box[Author] so you could get it like this

  aBook.author.obj match {
    case Full(a) = a // do something with the autor
    case Empty = // if the box is empty, handle it somehow
    case _ =  // should cover everyhting else, Failure etc

  }

  Hope it helps

      Other than that, so far, it's gone extremely well and I was able to
   get something up and running very quickly which really is a testament
   to the design of the framework.

      Thanks.

   Cheers,
   Achint

   --
   You received this message because you are subscribed to the Google Groups 
   Lift group.
   To post to this group, send email to lift...@googlegroups.com.
   To unsubscribe from this group, send email to 
   liftweb+unsubscr...@googlegroups.com.
   For more options, visit this group 
   athttp://groups.google.com/group/liftweb?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: Javascript Dependencies



On Mar 6, 9:14 pm, Peter Robinett pe...@bubblefoundry.com wrote:
 Hi guys,

 Sorry I'm only coming back to this discussion now. I think what you're
 both proposing are the two parts of what should be the complete use-
 case. Yes, dependencies _exist_ per page and, yes, you want to
 _declare_ them per snippet or CometActor. The last (and only) commit
 on my pr1001_issue_branch shows my first stab at managing and
 registering the 
 dependencies:http://github.com/dpp/liftweb/tree/pr1001_issue_281.
 I think it is quite similar to what has been mentioned (compare
 JsScript to Marius' JsDependenciesTree, ignoring that his is more
 elegant =).

 I think my resolve and satisfied_? methods work correctly, though they
 still need someone with some CS knowledge to check them (for instance,
 I'm not doing any checks for circular dependencies right now). The
 only real question is _when_ to call them and how to act upon them. I
 was thinking at the snippet level, not the page level. Anything
 outputting (X)HTML to the browser needs to be able to register their
 dependencies (CometActors by their nature should really only do it in
 their initial render) for a page-wide set of dependencies which are
 then resolved and merged into the head of the HTML document when the
 page is finally rendered.

Hmmm ... anything that is outputting (x)html. We have snippets, comet
actors, LiftView-s. Any of these can called multiple times but IMHO
registration should happen once. For snippets and comet we could a
nested snippet such as:


lift:MySnipet.work
  lift:dependencies
script src=bla.js/
   // you got the idea
  /lift:dependencies
  // specific tags
/lift:MySnipet.work


lift:comet ...
  lift:dependencies
script src=bla.js/
   /// you got the ides
  /lift:dependencies
  ...
/lift:comet


In this sense we are describing dependencies (could be both js and
css) per snippet / per comet. the dependencies snippet could be either
eagerly evaluated or not - shouldn't really matter. What it does it
just put the script and link tags in a head element that lift will
automatically merge.


This could also be useful for conditional snippets . Say we have
snippet A and snippet B on the same page each having different
dependencies. But snippet A is invoked only when the user is logged on
and snippet B only when user is logged off. Thus we won't have to
modify scala API at all. Cause it seems that Lift already provides the
goodies for us. Of course this can work even today if we replace
lift:dependencies with head tag but people would probably find
this nomenclature odd.

I'm not sure if we should worry about circular dependencies in this
case and neither for duplicates as lift head merge mechanism detects
duplicates.


I think this would cover snippets and comet actors and it should also
work for LiftView-s

Thoughts ?


 So, what if we have something like req.registerDependency(myJsScript)?
 The Request would store the dependencies that the LiftResponse would
 then take, resolve, and merge into the XHTML it's outputting. However,
 CometActors exist outside of normal requests. How do we get around
 this? CometActors are created initially in a Request, so we should be
 able to connect then but I don't know that part of Lift well enough to
 say how.

 Jeppe, Marius, what do you think? Am I on the right track? Do my
 suggestions address both of your concerns?

 Peter

 On Mar 1, 7:17 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:



  Marius marius.dan...@gmail.com writes:
   Yes we do have different perspectives. I'm saying for page X here
   these are the JS dependencies whether you seem to say here is a
   snippet, and it needs these dependencies

  Yes

   I'd still prefer my paradigm (not because of my ego) because it'd be
   easier to manage redundancies, it applies generically for snippets,
   comet actors etc. without having to induce other type of API. It is
   maybe coarse grained vs. your proposal that seems to me finner
   grained.

  I think the two can co-exist, although I haven't thought it through wrt
  comet actors etc. That was what I was hinting at in the previous
  mail. At the of the day (or before sending a response at least :-) a
  page needs to have a well-defined list of script files to include.

  So it makes sense to start with your paradigm and my paradigm should
  be able to be layered on top if one wishes...

   However I'd be happy to see an implementation of any of these
   proposals. Maybe other people would have better ideas so perhaps Peter
   and/oryou could dig could make this happen?

  I'll let Peter take the lead and help where ever I can :-)

  /Jeppe

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: superficial first impressions from a rails junkie



On Mar 6, 11:35 am, David Pollak feeder.of.the.be...@gmail.com
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 lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: [lift] superficial first impressions from a rails junkie

2010-03-06 Thread cageface

On Mar 6, 10:06 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
 And where are the bugs in the existing user guide?

The only outright bug is that you can't copy  paste the second maven
invocation and the fix is extremely non-obvious.

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: superficial first impressions from a rails junkie

2010-03-06 Thread cageface

On Mar 6, 12:05 pm, cody koeninger c...@koeninger.org wrote:
 How long had that getting started document been broken before it got
 fixed (assuming it's fixed now)?.

It's still broken.

 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.

I've actually been learning Clojure and Scala in parallel and dabbling
with Compojure a bit. It's obviously taking a totally different
approach than Lift but I can see myself using it for a couple of
simple, non-critical little apps I have to write in the next month.

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: superficial first impressions from a rails junkie

2010-03-06 Thread Timothy Perrett


  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.

Im not sure it is difficult to copy and paste:
mvn archetype:generate -DarchetypeCatalog=http://scala-tools.org/

Its one line... easy. Im not saying maven does not suck, but this is
one the wiki home page people...

 I don't see a how to use SBT or how to make Maven suck less  page
 in the wiki, can I write one?

The wiki is completely open. Yes.

 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.

Disagree. The archetypes use bind these days so im not sure how we are
promoting use of HTML literals. Personally, I always always use bind.

Cheeers, Tim

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: superficial first impressions from a rails junkie

2010-03-06 Thread cageface

On Mar 6, 12:20 pm, Timothy Perrett timo...@getintheloop.eu wrote:
 Im not sure it is difficult to copy and paste:
 mvn archetype:generate -DarchetypeCatalog=http://scala-tools.org/

 Its one line... easy. Im not saying maven does not suck, but this is
 one the wiki home page people...

When I try this it prompts me for all the other values that were
specified in the full invocation in the guide. If I'm a newcomer I
have no idea what groupid, artifactid, version and package should be.

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: Problem with FocusOnLoad and passing attributes through bind

You could also do it like this:

   bind(ajax, xhtml,
   searchBox -% SHtml.ajaxText(, q = SetHtml(resultz,
Yawni.query(q))
   )  ++ Script(JqOnLoad(SetValueAndFocus(myfield, )))

SetValueAndFocus is already in JqJsCmds but it really should in in
JsCmds as it does not depend on JQuery.



On Mar 6, 10:10 pm, Marius marius.dan...@gmail.com wrote:
 Ahh sorry for not posting this earlier.

 Assume you know the id of your text box (say myfield) and you're using
 JQuery.

 import net.liftweb.http.js.jquery._

    bind(ajax, xhtml,
            searchBox -% SHtml.ajaxText(, q = SetHtml(resultz,
 Yawni.query(q))
    )  ++ Script(JqOnLoad(JqFocus(myfield)))

 where:

   object JqFocus {
     def apply(id : String) = JqId(id)  new JsExp with JQueryRight {
       def toJsCmd = focus()
     }
   }

 I can add JqFocus to Lift tomorrow (by opening a ticket) but could you
 please try it first?

 Br's,
 Marius

 On Mar 6, 9:00 pm, Luke  Nezda lne...@gmail.com wrote:



  Marius -

  First, thank you for your time! (sorry for the accidental double
  response post - browser fail :))

  Ok, so below is my current solution.  What I don't understand is how
  to avoid hard coding the attributes when constructing the
  SHtml.ajaxText AND getting that ajaxText's input to FocusOnLoad.  I
  understand how to leave off the parameter for doSearch (fixed below --
  you're totally right, that was spurious) and I understand that passing
  through attributes to a whole NodeSeq doesn't make much sense.  What
  I'm wondering is if there's some way of achieving both: FocusOnLoad 
  attribute pass through -- maybe a nested bind or something?

  Thanks again,
  - Luke

  // get FocusOnLoad, hard code attributes
  object AjaxWithFocusOnLoad extends DispatchSnippet {
    override def dispatch = {
      case searchField = searchField
    }
    // searchField closure
    def searchField(xhtml: NodeSeq): NodeSeq = {
      // build up an ajax text box
      def doSearch:NodeSeq = {
        FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
  Yawni.query(q)), (size,30), (tabindex, 1), (type,
  search)))
      }
      // bind the view to the functionality
      bind(ajax, xhtml,
           searchBox - doSearch
           )
    }

  }

  // ditch FocusOnLoad functionality, take advantage of attribute pass
  through
  object AjaxWithAttributePassThrough extends DispatchSnippet {
    override def dispatch = {
      case searchField = searchField
    }
    // searchField closure
    def searchField(xhtml: NodeSeq): NodeSeq = {
      // build up an ajax text box
      def doSearch:Elem = {
        //FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
  Yawni.query(q)), (size,30), (tabindex, 1), (type,
  search)))
        // kill FocusOnLoad functionality, take advantage of attribute
  pass through in bind below
        SHtml.ajaxText(, q = SetHtml(resultz, Yawni.query(q)))
      }
      // bind the view to the functionality
      bind(ajax, xhtml,
           //searchBox - doSearch
           // use attribute pass through variant
           searchBox -% doSearch
           )
    }

  }

  On Mar 6, 10:57 am, Marius marius.dan...@gmail.com wrote:

   In the short term you would solve it as I suggested:

   Use in your bind

    searchBox -% doSearch

   and define your doSearch as:

   def doSearch: NodeSeq =  {
   ... do your stuff here

   }

   Actually thinking more into it there is a good reason for -% to not
   have a (NodeSeq) = NodeSeq support. -% means that it preserves the
   attributes specified in the template to the resulting node.But having
   a bunch of attributes we can't apply them to a NodeSeq because aa
   NodeSeq means a sequence of Nodes with no commn parent so we can;t
   determine to which node we'd apply those attributes. AFAIK only an
   Elem can have attributes.

   On Mar 6, 6:45 pm, Luke  Nezda lne...@gmail.com wrote:

Thanks for responding Marius.  You're right, my doSearch method
doesn't need the msg parameter -- that was just an artifact of
transforming an example (removed now).  As far as my specific issue, I
guess you're saying the best solution is for the framework to add
overload def -%(in: NodeSeq = NodeSeq) congruent with - -- should I
file a feature request?  As you said, Group(FocusOnLoad...) doesn't
compile either because it returns a Node, not the currently required
Element.  Did I misunderstand?  

   You are correct. I mainly pointed to Group just as a reminder as it
   can be useful to aggregate nodes. It wont work in your case.

   In the short term how would you solve

this ?

Thanks,
- Luke

On Mar 6, 1:39 am, Marius marius.dan...@gmail.com wrote:

 On 22 feb., 04:12, Luke  Nezda lne...@gmail.com wrote:

  Hello,

  I am new to Scala and Lift.  I am having a problem using 2 features
  together which seem to work fine individually.  Here's a simplified
  piece of the code:

  class Ajax {
    def someResult(q:String) = spansome

Re: [Lift] Re: superficial first impressions from a rails junkie

2010-03-06 Thread Mads Hartmann Jensen

If you're using TextMate you can navigate through your snippets/models quite 
easily - I've implemented a nifty little feature: 
http://www.youtube.com/watch?v=MXMh_uoeeTs

Now I know this is only for TextMate but I'm sure it wouldn't be too big a 
hassle to implemented in whatever editor/IDE you favor :) 
 

On 06/03/2010, at 21.36, Timothy Perrett wrote:

 
 Back when I was doing Rails, the state of Rails' documentation was not
 materially different from the current state of Lift's documentation with the
 exception of DHH's awesome book (which is my all time favorite tech book).
 Most of the online documentation was weak or non-existent.
 
 This is true, but *getting started* was extremely easy. A few very non-
 intimidating commands and you were up  running and making quick edits
 that appeared in real time. Once you started to dig a little deeper
 you ran into the problems you describe but by that point the fish was
 already on the hook.
 
 See:
 http://code.google.com/p/simple-build-tool/wiki/Processors
 
 This is what I am working on with Mark Harrah. We will ultimately have
 a simple lift command in the SBT shell... As i said before (and it
 appears to have been ignored) we are working on this, and its going to
 give us a very robust platform and vastly improve user experience.
 
 While I'm not sure I 100% agree with Tim's 6 million dollar man argument
 about PDF, PDF is common and useful... Scribd (which is definitely in the
 hip-cool-kids side of street) is built on PDF.
 
 PDF is great if you're making an ebook. It loses on every other score.
 I have to download it each time it's updated. I can't link into it
 from other sites.
 
 HAHA... well i wont start an argument on that, i'll just say that we
 as an organisation have tens of millions of dollars invested in PDF...
 its not going anywhere from the IT eco-system and I generally disagree
 with your points but I wont get into the finer points of electronic
 document creation.
 
 Okay... sorry... but this is a gratuitous swipe.  Ugly == Not Easy to Use.
 Nope.  Sorry.  I don't buy this.
 
 It's because of this - it suggests that the people behind the docs
 don't have either the time or the inclination to attend to the little
 details, which implies that other details might also be overlooked. If
 making attractive  easy to read introductory materials isn't a
 priority for the developers, maybe they also don't care about making
 the rest of the experience pleasant.
 
 Im not sure I agree (experience tells me developers are more
 pragmatic), but I take your point.
 
 I haven't found this to be the case at all. I build a new ruby into a
 separate install prefix and gem install rails and I'm ready to go. I
 certainly don't have to deal with anything approaching the complexity
 and inscrutability of a 152 line pom.xml.
 
 See above about SBT. Moreover, what was your feeling the first time
 you saw a complex rake file? Im not defending maven, rather, just
 think of the similar reaction.
 
 I do 50% of my coding with Emacs and my fingers do the right thing.  Those
 using TextMate or an IDE don't worry at all.
 
 I already hate having to navigate 3 directory levels in rails, even
 with ido mode. Three *more* tabs to each file doesn't sound like fun.
 
 As was already discussed, its only 3 more levels if you use the java
 package naming. Call it whatever you want.
 
 Cheers, Tim
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.
 

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: superficial first impressions from a rails junkie



On Mar 6, 2:20 pm, Timothy Perrett timo...@getintheloop.eu wrote:
   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.

 Im not sure it is difficult to copy and paste:
 mvn archetype:generate -DarchetypeCatalog=http://scala-tools.org/

 Its one line... easy. Im not saying maven does not suck, but this is
 one the wiki home page people...


My boss wants to check out lift, help the html designer do some
template cleanup.  He goes to liftweb.net, clicks on getting started
(a pretty reasonable first choice).  Finds the section on creating a
new project, copies the maven command.  It doesn't work, with a
cryptic error.  He's a smart enough guy to eventually figure out to
put it all on one line in the shell, but what do you think his
impression of the project is at this point?



  I don't see a how to use SBT or how to make Maven suck less  page
  in the wiki, can I write one?

 The wiki is completely open. Yes.


Ok, cool, i'll try to get something up soon.  What's the process for
getting http://liftweb.net/docs/getting_started/mod_master.html
changed, since at this point there's been more talking about it than
the time it would actually have taken to fix.


  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.

 Disagree. The archetypes use bind these days so im not sure how we are
 promoting use of HTML literals. Personally, I always always use bind.

 Cheeers, Tim



http://liftweb.net/docs/getting_started/mod_master.html
http://groups.google.com/group/the-lift-book

class HelloWorld {
 def howdy: NodeSeq =
   spanWelcome to helloworld at {new java.util.Date}/span
}


As you say, the current archetypes use bind, but how is a newcomer
even going to find those when the most obvious references on the
homepage are all to 1.0 era code?  The first time I looked at lift, I
read the first couple of chapters of the lift book and disregarded it
for exactly this reason.


-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: Problem with FocusOnLoad and passing attributes through bind

2010-03-06 Thread Luke Nezda

Hi, Marius -

Ok, I think I catch the drift of your solution.  You said:

bind(ajax, xhtml,
 searchBox -% SHtml.ajaxText(, q = SetHtml(resultz,
 Yawni.query(q))
) ++ Script(JqOnLoad(SetValueAndFocus(myfield, )))

which is missing a paren -- I think you meant:

bind(ajax, xhtml,
 searchBox -% SHtml.ajaxText(, q = SetHtml(resultz,
 Yawni.query(q)))
) ++ Script(JqOnLoad(SetValueAndFocus(myfield, )))

The gist of your solution is to append a Script (which references the
ajaxText input element by a manually introduced id) onto the NodeSeq
returned by bind() right ?

It works, and I appreciate your assistance, though it seems a shame to
have to give up the slick, functional FocusOnLoad wrapper, add an id,
and bolt this onto the end.

Thanks,
- Luke

On Mar 6, 2:39 pm, Marius marius.dan...@gmail.com wrote:
 You could also do it like this:

    bind(ajax, xhtml,
            searchBox -% SHtml.ajaxText(, q = SetHtml(resultz,
 Yawni.query(q))
    )  ++ Script(JqOnLoad(SetValueAndFocus(myfield, )))

 SetValueAndFocus is already in JqJsCmds but it really should in in
 JsCmds as it does not depend on JQuery.

 On Mar 6, 10:10 pm, Marius marius.dan...@gmail.com wrote:

  Ahh sorry for not posting this earlier.

  Assume you know the id of your text box (say myfield) and you're using
  JQuery.

  import net.liftweb.http.js.jquery._

     bind(ajax, xhtml,
             searchBox -% SHtml.ajaxText(, q = SetHtml(resultz,
  Yawni.query(q))
     )  ++ Script(JqOnLoad(JqFocus(myfield)))

  where:

    object JqFocus {
      def apply(id : String) = JqId(id)  new JsExp with JQueryRight {
        def toJsCmd = focus()
      }
    }

  I can add JqFocus to Lift tomorrow (by opening a ticket) but could you
  please try it first?

  Br's,
  Marius

  On Mar 6, 9:00 pm, Luke  Nezda lne...@gmail.com wrote:

   Marius -

   First, thank you for your time! (sorry for the accidental double
   response post - browser fail :))

   Ok, so below is my current solution.  What I don't understand is how
   to avoid hard coding the attributes when constructing the
   SHtml.ajaxText AND getting that ajaxText's input to FocusOnLoad.  I
   understand how to leave off the parameter for doSearch (fixed below --
   you're totally right, that was spurious) and I understand that passing
   through attributes to a whole NodeSeq doesn't make much sense.  What
   I'm wondering is if there's some way of achieving both: FocusOnLoad 
   attribute pass through -- maybe a nested bind or something?

   Thanks again,
   - Luke

   // get FocusOnLoad, hard code attributes
   object AjaxWithFocusOnLoad extends DispatchSnippet {
     override def dispatch = {
       case searchField = searchField
     }
     // searchField closure
     def searchField(xhtml: NodeSeq): NodeSeq = {
       // build up an ajax text box
       def doSearch:NodeSeq = {
         FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
   Yawni.query(q)), (size,30), (tabindex, 1), (type,
   search)))
       }
       // bind the view to the functionality
       bind(ajax, xhtml,
            searchBox - doSearch
            )
     }

   }

   // ditch FocusOnLoad functionality, take advantage of attribute pass
   through
   object AjaxWithAttributePassThrough extends DispatchSnippet {
     override def dispatch = {
       case searchField = searchField
     }
     // searchField closure
     def searchField(xhtml: NodeSeq): NodeSeq = {
       // build up an ajax text box
       def doSearch:Elem = {
         //FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
   Yawni.query(q)), (size,30), (tabindex, 1), (type,
   search)))
         // kill FocusOnLoad functionality, take advantage of attribute
   pass through in bind below
         SHtml.ajaxText(, q = SetHtml(resultz, Yawni.query(q)))
       }
       // bind the view to the functionality
       bind(ajax, xhtml,
            //searchBox - doSearch
            // use attribute pass through variant
            searchBox -% doSearch
            )
     }

   }

   On Mar 6, 10:57 am, Marius marius.dan...@gmail.com wrote:

In the short term you would solve it as I suggested:

Use in your bind

 searchBox -% doSearch

and define your doSearch as:

def doSearch: NodeSeq =  {
... do your stuff here

}

Actually thinking more into it there is a good reason for -% to not
have a (NodeSeq) = NodeSeq support. -% means that it preserves the
attributes specified in the template to the resulting node.But having
a bunch of attributes we can't apply them to a NodeSeq because aa
NodeSeq means a sequence of Nodes with no commn parent so we can;t
determine to which node we'd apply those attributes. AFAIK only an
Elem can have attributes.

On Mar 6, 6:45 pm, Luke  Nezda lne...@gmail.com wrote:

 Thanks for responding Marius.  You're right, my doSearch method
 doesn't need the msg parameter -- that was just an artifact of
 transforming an example

[Lift] Re: Problem with FocusOnLoad and passing attributes through bind

Yes you understanding is correct.

FocusOnLoad is not an appropriate solution for your particular problem
as -% and FocusOnLoad operate on two different types which are not
interchangeable due to attributes preservation as you well noticed.

Besides the solution I posted above is similar with what FocusOnLoad
does except that it does the Script append a bit later on.

FocusOnLoad is not really functional well not in the sense of
functional programming :)

There are other approaches of course but would require more coding as
form the NodeSeq produced by FocusOnLoad(Shtml.ajaxText()) pattern
match for the Elem you want that add the attributes.

You could of course put the js code that puts the focus on your field
right in your template in the script tag and this would require no
Scala code for it. you code would simply be

bind(ajax, xhtml,
 searchBox -% SHtml.ajaxText(, q = SetHtml(resultz,
Yawni.query(q)))
)

and in your template

script type=text/javascript

  $(document).ready(function() {
$(#myfield).focus();
  });

/script

On 6 mar., 23:56, Luke  Nezda lne...@gmail.com wrote:
 Hi, Marius -

 Ok, I think I catch the drift of your solution.  You said:

     bind(ajax, xhtml,
          searchBox -% SHtml.ajaxText(, q = SetHtml(resultz,
          Yawni.query(q))
     ) ++ Script(JqOnLoad(SetValueAndFocus(myfield, )))

 which is missing a paren -- I think you meant:

     bind(ajax, xhtml,
          searchBox -% SHtml.ajaxText(, q = SetHtml(resultz,
          Yawni.query(q)))
     ) ++ Script(JqOnLoad(SetValueAndFocus(myfield, )))

 The gist of your solution is to append a Script (which references the
 ajaxText input element by a manually introduced id) onto the NodeSeq
 returned by bind() right ?

 It works, and I appreciate your assistance, though it seems a shame to
 have to give up the slick, functional FocusOnLoad wrapper, add an id,
 and bolt this onto the end.

 Thanks,
 - Luke

 On Mar 6, 2:39 pm, Marius marius.dan...@gmail.com wrote:



  You could also do it like this:

     bind(ajax, xhtml,
             searchBox -% SHtml.ajaxText(, q = SetHtml(resultz,
  Yawni.query(q))
     )  ++ Script(JqOnLoad(SetValueAndFocus(myfield, )))

  SetValueAndFocus is already in JqJsCmds but it really should in in
  JsCmds as it does not depend on JQuery.

  On Mar 6, 10:10 pm, Marius marius.dan...@gmail.com wrote:

   Ahh sorry for not posting this earlier.

   Assume you know the id of your text box (say myfield) and you're using
   JQuery.

   import net.liftweb.http.js.jquery._

      bind(ajax, xhtml,
              searchBox -% SHtml.ajaxText(, q = SetHtml(resultz,
   Yawni.query(q))
      )  ++ Script(JqOnLoad(JqFocus(myfield)))

   where:

     object JqFocus {
       def apply(id : String) = JqId(id)  new JsExp with JQueryRight {
         def toJsCmd = focus()
       }
     }

   I can add JqFocus to Lift tomorrow (by opening a ticket) but could you
   please try it first?

   Br's,
   Marius

   On Mar 6, 9:00 pm, Luke  Nezda lne...@gmail.com wrote:

Marius -

First, thank you for your time! (sorry for the accidental double
response post - browser fail :))

Ok, so below is my current solution.  What I don't understand is how
to avoid hard coding the attributes when constructing the
SHtml.ajaxText AND getting that ajaxText's input to FocusOnLoad.  I
understand how to leave off the parameter for doSearch (fixed below --
you're totally right, that was spurious) and I understand that passing
through attributes to a whole NodeSeq doesn't make much sense.  What
I'm wondering is if there's some way of achieving both: FocusOnLoad 
attribute pass through -- maybe a nested bind or something?

Thanks again,
- Luke

// get FocusOnLoad, hard code attributes
object AjaxWithFocusOnLoad extends DispatchSnippet {
  override def dispatch = {
    case searchField = searchField
  }
  // searchField closure
  def searchField(xhtml: NodeSeq): NodeSeq = {
    // build up an ajax text box
    def doSearch:NodeSeq = {
      FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
Yawni.query(q)), (size,30), (tabindex, 1), (type,
search)))
    }
    // bind the view to the functionality
    bind(ajax, xhtml,
         searchBox - doSearch
         )
  }

}

// ditch FocusOnLoad functionality, take advantage of attribute pass
through
object AjaxWithAttributePassThrough extends DispatchSnippet {
  override def dispatch = {
    case searchField = searchField
  }
  // searchField closure
  def searchField(xhtml: NodeSeq): NodeSeq = {
    // build up an ajax text box
    def doSearch:Elem = {
      //FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
Yawni.query(q)), (size,30), (tabindex, 1), (type,
search)))
      // kill FocusOnLoad functionality, take advantage of attribute
pass through in bind below
      SHtml.ajaxText(, q =

[Lift] Re: superficial first impressions from a rails junkie

2010-03-06 Thread ced

This thread is another nice example of the kindly atmosphere within
the Lift community!

It's already late so I don't want to join the discussion in detail ;)

The only thing I'd like to add to the documentation talk is that I'd
really appreciate to have an up-to-date aggregated scaladoc of all the
Lift modules at hand. When looking for a new framework or library the
first thing I'd like to have a look at after reading the homepage is
the javadoc/scaladoc. This always gives me a good impression of the
state of a project. Unfortunately this is not very good with Lift. All
the links I've found either point to old versions (the prominent one
placed on http://liftweb.net/ shows the 1.0 API) or they just show one
module with all the links into another modules being broken.
Generating a complete scaladoc with mvn site works, but documenation
is scattered into pieces located into the various target/site
directories. However, I think presenting the API prominently to the
outside world is a good (and not so expensive) advertisement for a
project at least for the developer audience.

Cheers,
Chris

PS. Keep up the great work!

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Newbie Q: can I manually create a LiftSession?

2010-03-06 Thread dave dearing

I opened a ticket (#406) in response to this and attached a modified version
of the hello world archetype.

https://liftweb.assembla.com/spaces/liftweb/tickets/406-create-init-a-liftsession-from-outside-a-lift-handled-request

Just let me know if anything is unclear!
dave

On Thu, Mar 4, 2010 at 10:30 AM, David Pollak feeder.of.the.be...@gmail.com
wrote:

Do you want to create/access a LiftSession from outside a Lift-handed
request, but make sure the same LiftSession is available when you access the
Lift parts of your app? (sorry, I want to make sure I understand the
problem)

Right now, there's no good way to do that... sorry :-(

Feel encouraged to open a ticket on it at
https://liftweb.assembla.com/spaces/liftweb/tickets It'd be ideal if you
could include a test application so we could verify it was doing the right
thing.

On Wed, Mar 3, 2010 at 6:04 PM, David Dearing dpdear...@gmail.com wrote:

I'm new to Lift and am trying to use Lift within a subpath of my web
application. For example, http://domain.com is an existing webapp,
but my LiftFilter handles the user_mgt subpath (http://domain.com/
user_mgt/* http://domain.com/%0Auser_mgt/*). My existing webapp
already handles user authentication,
but I want to use the lost/change password functionality of Lift's
MegaProtoUser.

How do I create a LiftSession from my existing webapp so that I can
call User.logUserIn(my_user)?

I am embedding my User.logUserIn call within S.initIfUninitted like
this:
S.initIfUninitted(my_lift_session.openOr(** SOMETHING? **))
{
User.logUserIn(user)
}

If a LiftSession exists, I can retrieve it and it works fine:
val my_lift_session = SessionMaster.getSession(current_session_id,
Empty)

However, when my_lift_session is Empty, I have tried:
LiftRules.sessionCreator(new
provider.servlet.HTTPServletSession(current_session), ))

which appears to create a new LiftSession, but when I actually
navigate to a page in the subpath
http://domain.com/user_mgt/change_password
it doesn't recognize that I've logged in. Perhaps when I load the
page http://domain.com/user_mgt/change_password it is creating a new
LiftSession even though one already exists?

I've been banging my head on this for a while.
Any help would be greatly appreciated!
dave

--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: Re: [lift] superficial first impressions from a rails junkie

You mistake different with harder. People who are used to one way to do
things will find different harder than the same.

No, I don't. Different *is* harder. When there is a convention it should be
followed unless there is a good reason not to do so. This is one of the half
dozen or so key principles of usability. When you choose to do something in
a way that requires extra effort - *especially* when there is a convention
you could have followed - then tell people, briefly, that you have a good
reason for doing so. One that will benefit them.

In the case of view-first, there are plenty of posts as to why it's
better.

Said posts won't help when trying to get more people to use Lift. It's up to
you to set your priorities, but if one of those is creating a framework that
people use in significant numbers then you can't adopt a People could read
posts attitude to your new user experience. Especially when RoR and Grails
have set the bar so high.

The couple of ports I've
done, I've seen some substantive code reductions and significant test code
reductions. And, what I've gotten in addition to a smaller code base is
higher performance, more security, and more maintainability. So, Lift is
in
fact not harder to use.

Sorry, no. A better result does NOT equal easier to use. It might equal
Easier to use for a superior programmer who has tougher requirements.
Otherwise Emacs and Latex would be easier to use than Word - and much
easier than Notepad. What you are saying is that Scala is more powerful.
Which is great, because in any software product category there are usually
three viable niches - easiest to use, cheapest, and most powerful. In your
shoes I'd think about going after that most powerful niche.

I know that you're anti marketing, but not all marketing is BS. A lot of it
- at least in technical products - is honest communication regarding the
niches that your product is designed for. If you don't tell potential Lift
users what Lift can do for them, why should they try it? There really isn't
a rational reason. And why create a framework which no one will use?

--
View this message in context:
http://old.nabble.com/superficial-first-impressions-from-a-rails-junkie-tp27802055p27808051.html
Sent from the liftweb mailing list archive at Nabble.com.

Re: [Lift] Re: Re: [lift] superficial first impressions from a rails junkie

On Sat, Mar 6, 2010 at 3:29 PM, jonathan mawson umpti...@gmail.com wrote:

You mistake different with harder. People who are used to one way to do
things will find different harder than the same.

No, I don't. Different *is* harder. When there is a convention it should be
followed unless there is a good reason not to do so. This is one of the
half
dozen or so key principles of usability. When you choose to do something in
a way that requires extra effort - *especially* when there is a convention
you could have followed - then tell people, briefly, that you have a good
reason for doing so. One that will benefit them.

In the case of view-first, there are plenty of posts as to why it's
better.

Said posts won't help when trying to get more people to use Lift. It's up
to
you to set your priorities, but if one of those is creating a framework
that
people use in significant numbers then you can't adopt a People could read
posts attitude to your new user experience. Especially when RoR and Grails
have set the bar so high.

The couple of ports I've
done, I've seen some substantive code reductions and significant test
code
reductions. And, what I've gotten in addition to a smaller code base is
higher performance, more security, and more maintainability. So, Lift is
in
fact not harder to use.

If there's no rational reason to use Lift, then perhaps you could find
another community to spend your time in.

And why create a framework which no one will use?

Yeah, there are 1,700 nobodies on the Lift list. The folks at FourSquare
and Novell and Innovation Games and Xerox and SAP and Siemenns and etc. are
nobody.

Lift is not a clone of any framework. It's different and there are reasons
for those differences. If you don't like them, please use what you like
best. Use what feels most comfortable for you. Use what works best for
you.

--
View this message in context:
http://old.nabble.com/superficial-first-impressions-from-a-rails-junkie-tp27802055p27808051.html
Sent from the liftweb mailing list archive at Nabble.com.

--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

Re: [Lift] Re: superficial first impressions from a rails junkie

On Sat, Mar 6, 2010 at 12:13 PM, cageface milese...@gmail.com wrote:

 On Mar 6, 9:35 am, David Pollak feeder.of.the.be...@gmail.com wrote:
  Back when I was doing Rails, the state of Rails' documentation was not
  materially different from the current state of Lift's documentation with
 the
  exception of DHH's awesome book (which is my all time favorite tech
 book).
  Most of the online documentation was weak or non-existent.

 This is true, but *getting started* was extremely easy.


Apparently you used Rails in a different era from me.

Rails and Ruby and Gem were not native on OS X (it became part of the OS in
10.4).  One had to be a serious guru to build and install the basic Ruby
system.   Even using RedHat and RPMs, it was a good 2 hours to get Ruby and
Gem and Rails installed.  Back in 2005-2006 Ruby and Rails were not easy to
get started with.

Once that was done, yes, the initial Rails project was easy to create... a
tad easier than Tim's 1 line Maven command, but not that much easier.


 A few very non-
 intimidating commands and you were up  running and making quick edits
 that appeared in real time.


Yep.  There is a difference between a statically compiled language and a
dynamic one.  There is a difference between keeping a fair amount of state
around and not.  There are costs and benefits with each.  While I would like
to make Lift easier to be change and reload out of the box, in general, if
that is the barrier to adoption for a certain segment, then so be it.


 Once you started to dig a little deeper
 you ran into the problems you describe but by that point the fish was
 already on the hook.


So, the key thing is what's the flash to bang.  Yes, these days, the flash
to bang with Rails is fast.  Maybe we should have built the real time chat
stuff as the first project.  http://liftweb.blip.tv/file/2033658/  It's
faster flash to bang.  But, I disagree with the assertion that the flash to
bang for Lift is long.  Yeah, if someone is going to spend 2 minutes with
Lift, we probably won't make a case.  If someone spends enough time to see
the Ajax features of Lift (especially coming from the Java frameworks, but
even coming from Rails), we get a substantial number of folks who are hooked
like
http://groups.google.com/group/liftweb/browse_thread/thread/136d2accec22f300?hl=en(Lift
is so complex but once you wrap your head around it is so easy :D )



  This is one of the things I wanted to do differently with Lift.  I didn't
  want to market it.  I wanted to build solid technology that addressed
  serious needs including security, highly interactive apps, and
 scalability.

 I started working with Lisp  other functional languages about 10
 years ago and it's been frustrating to watch inferior languages like
 Ruby and Python sail past them in popularity over that time. I think a
 lot of this has to do with a naivety in the functional programming
 community that solving the hard problems is what matters and that
 people will naturally  logically adopt tools that do this.
 Unfortunately, it appears that the opposite is much more often then
 case and that people choose easy  fashionable first.


A big part of gaining long term adoption of any technology is timing the
chasm crossing such that when the chasm is crossed, there is long term
sustainability.

DHH promoted Rails too early in my opinion.  VeriSign adopted Rails for some
projects and after deploying those projects and then paying Zed Shaw to
write Mongrel, VeriSign dumped Rails.  Had Rails been lower visibility, the
Rails community would not have suffered through this embarrassment followed
by the Twitter embarrassment.  To this day, even though Rails has high
visibility and is more stable than it used to be, it is still tarred on the
corporate side with the doesn't scale moniker.  This has opened the doors
for Grails.

Another failing of Rails is the community.  The Rails community is a
significant detractor to adoption outside of the young hip kids.

What we have in Lift is very solid technology, an excellent community,
tremendous committers, and an increasing number of very high profile
projects built on Lift.  These are very solid, very defensible assets.  But
I'd rather try to cross the chasm and actively promote Lift and Scala to the
broader community when we know what community we're promoting to (hip Web
2.0+ kids, Enterprisy folks, ???), what the real value proposition is, and
when we have a revenue model that is not based on selling out to the likes
of Sun or VMWare.  As an aside, I've been getting calls from VCs lately
about investing in Lift  Scala.  Some of them just want to bet on a horse
and some of them have been actively working with me, Martin and others to
figure out what Lift and Scala look like across the chasm.

But right now, Lift is a community, committers and excellent technology for
building secure, maintainable, highly interactive web sites.  When it's time
to build a business around Lift and Scala, you will see

[Lift] Re: superficial first impressions from a rails junkie

On Mar 6, 7:28 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
 Another failing of Rails is the community.  The Rails community is a
 significant detractor to adoption outside of the young hip kids.

The rails community is a significant detractor to adoption even among
young hip kids. . . I hope I'm not the only one disgusted by the
response to the whole porn star fiasco.


 is a huge selling point on its own.  Especially when the time to get started
 with Lift is less than a day and the time to get started with Rails is about
 a day.


As a reality check here, I saw several people at SnapCamp use up more
than half of the first day just trying to get a Lift hello world
running in their development environment, never mind understanding the
basics of the framework.  People at work had been writing lift code
for a couple months and were still uncertain about when to use
stateful snippets, session vars,  request vars, or just setting vars
from closures.  I'm not going to claim to have any empirical
comparisons to rails, but my recollection from the 5 year old rails
book was that it made it pretty obvious where things went and how to
do things.

Enabling people who are interested in decent documentation to fix
minor issues that have been repeatedly identified is a far cry from
overpromoting too early or acting like rock stars.

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: superficial first impressions from a rails junkie

2010-03-06 Thread Naftoli Gugenheim

I think I understand David's point about letting Lift sell itself for now,
rather than pushing for more widespread adoption, until the right time comes
At the same time I would like to mention that it seems to me (not based on
any experience) than Jonathan Mawson has very good marketing sense / common
sense. I think that with David's direction, if Jonathan is interested he
could contribute a lot with his suggestions and helping implement them.
For example, revising the selling points in a way that David and Jonathan
agree on could be very valuable.
I'm sure that if he puts his mind to it, he will have a lot of ideas that
are good for Lift.


On Sat, Mar 6, 2010 at 8:28 PM, David Pollak
feeder.of.the.be...@gmail.comwrote:



 On Sat, Mar 6, 2010 at 12:13 PM, cageface milese...@gmail.com wrote:

 On Mar 6, 9:35 am, David Pollak feeder.of.the.be...@gmail.com wrote:
  Back when I was doing Rails, the state of Rails' documentation was not
  materially different from the current state of Lift's documentation with
 the
  exception of DHH's awesome book (which is my all time favorite tech
 book).
  Most of the online documentation was weak or non-existent.

 This is true, but *getting started* was extremely easy.


 Apparently you used Rails in a different era from me.

 Rails and Ruby and Gem were not native on OS X (it became part of the OS in
 10.4).  One had to be a serious guru to build and install the basic Ruby
 system.   Even using RedHat and RPMs, it was a good 2 hours to get Ruby and
 Gem and Rails installed.  Back in 2005-2006 Ruby and Rails were not easy to
 get started with.

 Once that was done, yes, the initial Rails project was easy to create... a
 tad easier than Tim's 1 line Maven command, but not that much easier.


 A few very non-
 intimidating commands and you were up  running and making quick edits
 that appeared in real time.


 Yep.  There is a difference between a statically compiled language and a
 dynamic one.  There is a difference between keeping a fair amount of state
 around and not.  There are costs and benefits with each.  While I would like
 to make Lift easier to be change and reload out of the box, in general, if
 that is the barrier to adoption for a certain segment, then so be it.


 Once you started to dig a little deeper
 you ran into the problems you describe but by that point the fish was
 already on the hook.


 So, the key thing is what's the flash to bang.  Yes, these days, the flash
 to bang with Rails is fast.  Maybe we should have built the real time chat
 stuff as the first project.  http://liftweb.blip.tv/file/2033658/  It's
 faster flash to bang.  But, I disagree with the assertion that the flash to
 bang for Lift is long.  Yeah, if someone is going to spend 2 minutes with
 Lift, we probably won't make a case.  If someone spends enough time to see
 the Ajax features of Lift (especially coming from the Java frameworks, but
 even coming from Rails), we get a substantial number of folks who are hooked
 like
 http://groups.google.com/group/liftweb/browse_thread/thread/136d2accec22f300?hl=en(Lift
  is so complex but once you wrap your head around it is so easy :D )



  This is one of the things I wanted to do differently with Lift.  I
 didn't
  want to market it.  I wanted to build solid technology that addressed
  serious needs including security, highly interactive apps, and
 scalability.

 I started working with Lisp  other functional languages about 10
 years ago and it's been frustrating to watch inferior languages like
 Ruby and Python sail past them in popularity over that time. I think a
 lot of this has to do with a naivety in the functional programming
 community that solving the hard problems is what matters and that
 people will naturally  logically adopt tools that do this.
 Unfortunately, it appears that the opposite is much more often then
 case and that people choose easy  fashionable first.


 A big part of gaining long term adoption of any technology is timing the
 chasm crossing such that when the chasm is crossed, there is long term
 sustainability.

 DHH promoted Rails too early in my opinion.  VeriSign adopted Rails for
 some projects and after deploying those projects and then paying Zed Shaw to
 write Mongrel, VeriSign dumped Rails.  Had Rails been lower visibility, the
 Rails community would not have suffered through this embarrassment followed
 by the Twitter embarrassment.  To this day, even though Rails has high
 visibility and is more stable than it used to be, it is still tarred on the
 corporate side with the doesn't scale moniker.  This has opened the doors
 for Grails.

 Another failing of Rails is the community.  The Rails community is a
 significant detractor to adoption outside of the young hip kids.

 What we have in Lift is very solid technology, an excellent community,
 tremendous committers, and an increasing number of very high profile
 projects built on Lift.  These are very solid, very defensible assets.  But
 I'd rather

Re: [Lift] Re: superficial first impressions from a rails junkie

2010-03-06 Thread Naftoli Gugenheim

Also, someone was lamenting GitHub's flat wiki. Assembla has a more advanced
wiki system but David said it's not worthwhile to move unless someone will
take on the role of managing the wiki.

On Sat, Mar 6, 2010 at 10:44 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:

 I think I understand David's point about letting Lift sell itself for now,
 rather than pushing for more widespread adoption, until the right time comes
 At the same time I would like to mention that it seems to me (not based on
 any experience) than Jonathan Mawson has very good marketing sense / common
 sense. I think that with David's direction, if Jonathan is interested he
 could contribute a lot with his suggestions and helping implement them.
 For example, revising the selling points in a way that David and Jonathan
 agree on could be very valuable.
 I'm sure that if he puts his mind to it, he will have a lot of ideas that
 are good for Lift.


 On Sat, Mar 6, 2010 at 8:28 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Sat, Mar 6, 2010 at 12:13 PM, cageface milese...@gmail.com wrote:

 On Mar 6, 9:35 am, David Pollak feeder.of.the.be...@gmail.com wrote:
  Back when I was doing Rails, the state of Rails' documentation was not
  materially different from the current state of Lift's documentation
 with the
  exception of DHH's awesome book (which is my all time favorite tech
 book).
  Most of the online documentation was weak or non-existent.

 This is true, but *getting started* was extremely easy.


 Apparently you used Rails in a different era from me.

 Rails and Ruby and Gem were not native on OS X (it became part of the OS
 in 10.4).  One had to be a serious guru to build and install the basic Ruby
 system.   Even using RedHat and RPMs, it was a good 2 hours to get Ruby and
 Gem and Rails installed.  Back in 2005-2006 Ruby and Rails were not easy to
 get started with.

 Once that was done, yes, the initial Rails project was easy to create... a
 tad easier than Tim's 1 line Maven command, but not that much easier.


 A few very non-
 intimidating commands and you were up  running and making quick edits
 that appeared in real time.


 Yep.  There is a difference between a statically compiled language and a
 dynamic one.  There is a difference between keeping a fair amount of state
 around and not.  There are costs and benefits with each.  While I would like
 to make Lift easier to be change and reload out of the box, in general, if
 that is the barrier to adoption for a certain segment, then so be it.


 Once you started to dig a little deeper
 you ran into the problems you describe but by that point the fish was
 already on the hook.


 So, the key thing is what's the flash to bang.  Yes, these days, the flash
 to bang with Rails is fast.  Maybe we should have built the real time chat
 stuff as the first project.  http://liftweb.blip.tv/file/2033658/  It's
 faster flash to bang.  But, I disagree with the assertion that the flash to
 bang for Lift is long.  Yeah, if someone is going to spend 2 minutes with
 Lift, we probably won't make a case.  If someone spends enough time to see
 the Ajax features of Lift (especially coming from the Java frameworks, but
 even coming from Rails), we get a substantial number of folks who are hooked
 like
 http://groups.google.com/group/liftweb/browse_thread/thread/136d2accec22f300?hl=en(Lift
  is so complex but once you wrap your head around it is so easy :D )



  This is one of the things I wanted to do differently with Lift.  I
 didn't
  want to market it.  I wanted to build solid technology that addressed
  serious needs including security, highly interactive apps, and
 scalability.

 I started working with Lisp  other functional languages about 10
 years ago and it's been frustrating to watch inferior languages like
 Ruby and Python sail past them in popularity over that time. I think a
 lot of this has to do with a naivety in the functional programming
 community that solving the hard problems is what matters and that
 people will naturally  logically adopt tools that do this.
 Unfortunately, it appears that the opposite is much more often then
 case and that people choose easy  fashionable first.


 A big part of gaining long term adoption of any technology is timing the
 chasm crossing such that when the chasm is crossed, there is long term
 sustainability.

 DHH promoted Rails too early in my opinion.  VeriSign adopted Rails for
 some projects and after deploying those projects and then paying Zed Shaw to
 write Mongrel, VeriSign dumped Rails.  Had Rails been lower visibility, the
 Rails community would not have suffered through this embarrassment followed
 by the Twitter embarrassment.  To this day, even though Rails has high
 visibility and is more stable than it used to be, it is still tarred on the
 corporate side with the doesn't scale moniker.  This has opened the doors
 for Grails.

 Another failing of Rails is the community.  The Rails community is a
 significant

[Lift] Re: Problem with FocusOnLoad and passing attributes through bind