[Lift] non-Lazy evaluation of bind FuncBindParam functions?

2010-03-10 Thread Stuart Roebuck
I've been trying to figure why some binding is giving me a stack
overflow and I've discovered that if you use the BindHelpers.bind
method with a set of function BindParams, all the functions are
evaluated regardless of whether a match is found.

So, for example, if you bind to an empty NodeSeq and have a BindParam
which will never match like:
  you won't find me here - { print(Got here!);
NodeSeq.Empty }
…you find that the print statement is called.

This really surprised me.  Is this intentional behaviour as it seems
to be a potential source of significant redundant processing?

Stuart.

-- 
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: non-Lazy evaluation of bind FuncBindParam functions?

2010-03-10 Thread Stuart Roebuck
Okay, so I now understand what is happening a little better.

When I saw a construct like:

  bind(example,xhtml,
first_name - SHtml.text(user.first_name, user.first_name(_)),
last_name - SHtml.text(user.last_name, user.last_name(_))

it reminded me of a match with cases and my assumption was that each
match would only be called if and when the match was found. In reality
what appears to happen is that the item on the right hand side of the
- is usually evaluated and then placed into a Map with the String
like first_name being the key.

So, if every binding is used in every case there is no big issue here,
but if you have bindings that aren't all used they will none-the-less
be evaluated every time you try to bind.

Also every time the bind function is called a new Map appears to be
generated and indexed in memory which doesn't seem as efficient as it
could be.

I can't help but wonder whether this could be converted to a form of
match which would then be built at compile time and re-used and would
only evaluate those matches that matched.

In the meantime I see that you can convert the code above to:

  bind(example,xhtml,
FuncBindParam(first_name, () = SHtml.text(user.first_name,
user.first_name(_)),
FuncBindParam(last_name, () = SHtml.text(user.last_name,
user.last_name(_))

to get a form of lazy evaluation.


On Mar 10, 11:01 am, Stuart Roebuck stuart.roeb...@gmail.com wrote:
 I've been trying to figure why some binding is giving me a stack
 overflow and I've discovered that if you use the BindHelpers.bind
 method with a set of function BindParams, all the functions are
 evaluated regardless of whether a match is found.

 So, for example, if you bind to an empty NodeSeq and have a BindParam
 which will never match like:
       you won't find me here - { print(Got here!);
 NodeSeq.Empty }
 …you find that the print statement is called.

 This really surprised me.  Is this intentional behaviour as it seems
 to be a potential source of significant redundant processing?

 Stuart.

-- 
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: non-Lazy evaluation of bind FuncBindParam functions?

2010-03-10 Thread Stuart Roebuck
Thanks for the feedback.  I'm not trying to be awkward here, just
trying to get my head around everything.

Oh, and I completely agree with the risks of premature optimisation.

Thanks,

Stuart

On Mar 10, 5:03 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
 On Wed, Mar 10, 2010 at 7:22 AM, Stuart Roebuck 
 stuart.roeb...@gmail.comwrote:

  Okay, so I now understand what is happening a little better.

  When I saw a construct like:

   bind(example,xhtml,
     first_name - SHtml.text(user.first_name, user.first_name(_)),
     last_name - SHtml.text(user.last_name, user.last_name(_))

  it reminded me of a match with cases and my assumption was that each
  match would only be called if and when the match was found. In reality
  what appears to happen is that the item on the right hand side of the
  - is usually evaluated and then placed into a Map with the String
  like first_name being the key.

 You're welcome to take up laziness vs. strictness with the EPFL team.
  There's only so much we can do to be lazy and it does take extra syntax
 (see Ross's reply).

  So, if every binding is used in every case there is no big issue here,
  but if you have bindings that aren't all used they will none-the-less
  be evaluated every time you try to bind.

  Also every time the bind function is called a new Map appears to be
  generated and indexed in memory which doesn't seem as efficient as it
  could be.

 There's a sign over a urinal in a mens room at Google that reads Premature
 Optimization is the root of all evil.  Now, I think that's an
 overstatement, but in this case, it's applicable.

 Is there an *actual* problem with building a Map()?  Can you measure the
 problem?  Do you have a more efficient solution?

 Now, when I wrote that particular code, I was very cognizant of the
 performance implications.

 The cost of producing the Map() (backed by a HashMap) in the normal case (no
 hash collisions) is O(n).  Worst case is O(n log n).

 For each element we're binding, we have look up the tag of the node to bind.
  If we are using our Map(), the look-up time is O(1) (or worst case O(log
 n)).  If we have n elements that we're binding, the expected cost is O(n)
 and worst case is O(n log n).

 So, we have an algorithm that normally executes in 2xO(n) and worst case
 2xO(n log n).

 Now, if we didn't create the Map, we'd have to cycle through the possible
 binds and we'd wind up with O(n ^ 2).  Even if you have a PartialFunction
 (pattern matching) against strings, it's O(n) to match the pattern.

 So, would you rather have an O(n) algorithm that can degrade to O(n log n)
 and uses marginally more memory or would you rather have an O(n ^ 2)
 algorithm that uses marginally less memory?

 And if you're worried about the memory used by the Map(), on pre 1.6 build
 16 JVMs, the Map will not likely escape the Eden memory pool (which means
 very quick GC).  On the most recent JVMs, the escape analysis should kick in
 and the Map and its elements will be allocated on the heap and never be
 subject to GC.



  I can't help but wonder whether this could be converted to a form of
  match which would then be built at compile time and re-used and would
  only evaluate those matches that matched.

 In the event that you can create a benchmark and a real-world situation that
 actually needs this, please open a ticket.  But, I suspect that even if you
 pre-created a Map and passed it into bind(), that the performance would be
 nearly identical, but we'd have more public APIs to document which seems to
 be something that also annoys you.







  In the meantime I see that you can convert the code above to:

   bind(example,xhtml,
     FuncBindParam(first_name, () = SHtml.text(user.first_name,
  user.first_name(_)),
     FuncBindParam(last_name, () = SHtml.text(user.last_name,
  user.last_name(_))

  to get a form of lazy evaluation.

  On Mar 10, 11:01 am, Stuart Roebuck stuart.roeb...@gmail.com wrote:
   I've been trying to figure why some binding is giving me a stack
   overflow and I've discovered that if you use the BindHelpers.bind
   method with a set of function BindParams, all the functions are
   evaluated regardless of whether a match is found.

   So, for example, if you bind to an empty NodeSeq and have a BindParam
   which will never match like:
         you won't find me here - { print(Got here!);
   NodeSeq.Empty }
   …you find that the print statement is called.

   This really surprised me.  Is this intentional behaviour as it seems
   to be a potential source of significant redundant processing?

   Stuart.

  --
  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

[Lift] NodeSeq to JsExp how to?

2010-03-09 Thread Stuart Roebuck
I'm trying to produce a web page with editable content.

When the user clicks an edit button on a line it uses jQuery to
display a modal dialog which allows fields of that line to be edited.

I can easily produce a snippet to produce the lines using the backend
data and an XHTML template and binding etc.

However, I also want the template to include the template for the
dialog.  So I want the ajax button callback to send JavaScript to
instantiate the jQuery UI dialog based on the template and bindings.

To build this I need to assemble a JsCmd containing the NodeSeq that
comes from the XHTML sequence and the bindings.

In short, if this was straight jQuery I would have some JavaScript of
the form:

$(div title=Dialog TitletheFormNodeSeq/div).dialog()

But in my case theFormNodeSeq comes from a NodeSeq that was assembled
from part of the XHTML template and the bindings and the end result
needs to be a JsCmd.

So I'm trying to do something like:

JsCmds.Run($( + theFormNodeSeq.toString + ).dialog())

But I need to address escaping issues with the HTML and I also need to
pre-process any lift:… / commands in theFormNodeSeq.

Any advice (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.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



[Lift] Re: NodeSeq to JsExp how to?

2010-03-09 Thread Stuart Roebuck
Thanks for that amazingly quick response!

I only wish I understood the proposed solution! :-)

So (confession time) I simplified things a little, the actual
JavaScript is…

var theDialog = $(…).dialog( { autoOpen: true, width: 500, modal:
true, close: function() { theDialog.destroy; }; } )

How do I assemble this, or is there any documentation / examples you
can point me to.

Thanks very much,

Stuart.

On Mar 9, 5:14 pm, Ross Mellgren dri...@gmail.com wrote:
 Whoops, I meant Str(fixHtml(...)) not JsStr(fixHtml(...))

 -Ross

 On Mar 9, 2010, at 12:14 PM, Ross Mellgren wrote:



  Try this (I haven't tested it, so there could be lurking bugs):

  case class JQueryNodeSeq(ns: NodeSeq) extends JsExp with JQueryLeft with 
  HtmlFixer {
     override def toJsCmd = jQuery( + JsStr(fixHtml(NodeSeqDialog, 
  ns)).toJsCmd + )
  }

  Then JQueryNodeSeq(ns) ~ JsFunc(dialog)

  -Ross

  On Mar 9, 2010, at 12:06 PM, Stuart Roebuck wrote:

  I'm trying to produce a web page with editable content.

  When the user clicks an edit button on a line it uses jQuery to
  display a modal dialog which allows fields of that line to be edited.

  I can easily produce a snippet to produce the lines using the backend
  data and an XHTML template and binding etc.

  However, I also want the template to include the template for the
  dialog.  So I want the ajax button callback to send JavaScript to
  instantiate the jQuery UI dialog based on the template and bindings.

  To build this I need to assemble a JsCmd containing the NodeSeq that
  comes from the XHTML sequence and the bindings.

  In short, if this was straight jQuery I would have some JavaScript of
  the form:

  $(div title=Dialog TitletheFormNodeSeq/div).dialog()

  But in my case theFormNodeSeq comes from a NodeSeq that was assembled
  from part of the XHTML template and the bindings and the end result
  needs to be a JsCmd.

  So I'm trying to do something like:

  JsCmds.Run($( + theFormNodeSeq.toString + ).dialog())

  But I need to address escaping issues with the HTML and I also need to
  pre-process any lift:… / commands in theFormNodeSeq.

  Any advice (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.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: NodeSeq to JsExp how to?

2010-03-09 Thread Stuart Roebuck
Ross,

Thanks - yes, the NodeSeq is all generated from templates internally.
The end user does not have any access to change this stuff so this
particular security issue shouldn't be a problem in this case.

Stuart.

On Mar 9, 5:30 pm, Ross Mellgren dri...@gmail.com wrote:
 Ah yes, the reason I went through the fixHtml route is because Stuart 
 specifically mentioned he wanted to process those.

 Stuart, you should make sure to properly secure this stuff -- either as an 
 admin-only thing (understanding that that person has as much rights as you) 
 or by scrubbing the XML thoroughly.

 -Ross

 On Mar 9, 2010, at 12:26 PM, David Pollak wrote:





  On Tue, Mar 9, 2010 at 9:14 AM, Ross Mellgren dri...@gmail.com wrote:
  Try this (I haven't tested it, so there could be lurking bugs):

  case class JQueryNodeSeq(ns: NodeSeq) extends JsExp with JQueryLeft with 
  HtmlFixer {
     override def toJsCmd = jQuery( + JsStr(fixHtml(NodeSeqDialog, 
  ns)).toJsCmd + )
  }

  Ross,

  This is good code, but introduces a potential security vulnerability. ;-)

  fixHtml runs the NodeSeq through Lift's snippet handler.  If you have 
  web-user input, a user could type in lift:/ and cause server-side 
  code to be executed.

  import net.liftweb.util._
  import Helpers._

  Personally, I'd suggest jQuery( + AltXML.toXML(nodeSeq, false, 
  true).encJs + )

  Thanks,

  David

  Then JQueryNodeSeq(ns) ~ JsFunc(dialog)

  -Ross

  On Mar 9, 2010, at 12:06 PM, Stuart Roebuck wrote:

   I'm trying to produce a web page with editable content.

   When the user clicks an edit button on a line it uses jQuery to
   display a modal dialog which allows fields of that line to be edited.

   I can easily produce a snippet to produce the lines using the backend
   data and an XHTML template and binding etc.

   However, I also want the template to include the template for the
   dialog.  So I want the ajax button callback to send JavaScript to
   instantiate the jQuery UI dialog based on the template and bindings.

   To build this I need to assemble a JsCmd containing the NodeSeq that
   comes from the XHTML sequence and the bindings.

   In short, if this was straight jQuery I would have some JavaScript of
   the form:

   $(div title=Dialog TitletheFormNodeSeq/div).dialog()

   But in my case theFormNodeSeq comes from a NodeSeq that was assembled
   from part of the XHTML template and the bindings and the end result
   needs to be a JsCmd.

   So I'm trying to do something like:

   JsCmds.Run($( + theFormNodeSeq.toString + ).dialog())

   But I need to address escaping issues with the HTML and I also need to
   pre-process any lift:… / commands in theFormNodeSeq.

   Any advice (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.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 
  athttp://groups.google.com/group/liftweb?hl=en.

  --
  Lift, the simply functional web frameworkhttp://liftweb.net
  Beginning Scalahttp://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 
  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: NodeSeq to JsExp how to?

2010-03-09 Thread Stuart Roebuck
Once again, thanks for all of this.  I will now go away and
contemplate it all.

On the face of it, as a newby, this JavaScript DSL adds another layer
of complexity to using Lift with JavaScript.  Is there an option to
use mostly raw JavaScript?  What are the advantages / disadvantages?

Sorry, I thought I'd get my moneys worth from you and then try to put
something onto the wiki.

Best,

Stuart.

On Mar 9, 5:35 pm, Ross Mellgren dri...@gmail.com wrote:
 That's why I factored this as a JQueryNodeSeq, so you can pass anything to 
 dialog (I've used JQuery, and figured you'd need to pass something in there 
 ;-)

 JQueryNodeSeq(ns) ~ JsFunc(dialog, JsObj(autoOpen - JsTrue, width - 
 500, ..., close - AnonFunc(JsVal(this) ~ JsFunc(destroy

  case class JQueryNodeSeq(ns: NodeSeq) extends JsExp with JQueryLeft with 
  HtmlFixer {

 JsExp is the basic trait of the JavaScript DSL. Anything that can go into a 
 JavaScript expression should have this trait.
 JQueryLeft is a trait used by the JQuery portion of the JavaScript DSL to 
 indicate that you can chain JQuery calls onto this.
 HtmlFixer is a trait that provides fixHtml

     override def toJsCmd = jQuery( + JsStr(fixHtml(NodeSeqDialog, 
  ns)).toJsCmd + )

 fixHtml takes the given NodeSeq and does all the appropriate magics to 
 process lift: tags and then converts the NodeSeq to valid XHTML.

  }

 And don't forget the security implications!

 Hope that helps,
 -Ross

 On Mar 9, 2010, at 12:30 PM, Stuart Roebuck wrote:



  Thanks for that amazingly quick response!

  I only wish I understood the proposed solution! :-)

  So (confession time) I simplified things a little, the actual
  JavaScript is…

  var theDialog = $(…).dialog( { autoOpen: true, width: 500, modal:
  true, close: function() { theDialog.destroy; }; } )

  How do I assemble this, or is there any documentation / examples you
  can point me to.

  Thanks very much,

  Stuart.

  On Mar 9, 5:14 pm, Ross Mellgren dri...@gmail.com wrote:
  Whoops, I meant Str(fixHtml(...)) not JsStr(fixHtml(...))

  -Ross

  On Mar 9, 2010, at 12:14 PM, Ross Mellgren wrote:

  Try this (I haven't tested it, so there could be lurking bugs):

  case class JQueryNodeSeq(ns: NodeSeq) extends JsExp with JQueryLeft with 
  HtmlFixer {
     override def toJsCmd = jQuery( + JsStr(fixHtml(NodeSeqDialog, 
  ns)).toJsCmd + )
  }

  Then JQueryNodeSeq(ns) ~ JsFunc(dialog)

  -Ross

  On Mar 9, 2010, at 12:06 PM, Stuart Roebuck wrote:

  I'm trying to produce a web page with editable content.

  When the user clicks an edit button on a line it uses jQuery to
  display a modal dialog which allows fields of that line to be edited.

  I can easily produce a snippet to produce the lines using the backend
  data and an XHTML template and binding etc.

  However, I also want the template to include the template for the
  dialog.  So I want the ajax button callback to send JavaScript to
  instantiate the jQuery UI dialog based on the template and bindings.

  To build this I need to assemble a JsCmd containing the NodeSeq that
  comes from the XHTML sequence and the bindings.

  In short, if this was straight jQuery I would have some JavaScript of
  the form:

  $(div title=Dialog TitletheFormNodeSeq/div).dialog()

  But in my case theFormNodeSeq comes from a NodeSeq that was assembled
  from part of the XHTML template and the bindings and the end result
  needs to be a JsCmd.

  So I'm trying to do something like:

  JsCmds.Run($( + theFormNodeSeq.toString + ).dialog())

  But I need to address escaping issues with the HTML and I also need to
  pre-process any lift:… / commands in theFormNodeSeq.

  Any advice (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.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 
  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: NodeSeq to JsExp how to?

2010-03-09 Thread Stuart Roebuck
Thanks Ross and David…  the code seems to be working great now.

Stuart.

On Mar 9, 10:16 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
 On Tue, Mar 9, 2010 at 1:11 PM, Stuart Roebuck 
 stuart.roeb...@gmail.comwrote:

  Once again, thanks for all of this.  I will now go away and
  contemplate it all.

  On the face of it, as a newby, this JavaScript DSL adds another layer
  of complexity to using Lift with JavaScript.  Is there an option to
  use mostly raw JavaScript?  What are the advantages / disadvantages?

 JsRaw(my JavaScript Here)

 The disadvantage is type-safety/having the compiler help you.

 I wrote most of the JavaScript helpers (or at least wrote the core stuff and
 other followed my pattern.)  A few months back, there was a discussion about
 changing that stuff around.  I'd like to see Lift's JavaScript helper be a
 lot more composable than they are now... like the Lift-json stuff and also
 integrate better with Lift-json.  But I don't see that happening with Lift
 2.0 unless there's a huge block of time/effort that someone wants to throw
 at the issue.







  Sorry, I thought I'd get my moneys worth from you and then try to put
  something onto the wiki.

  Best,

  Stuart.

  On Mar 9, 5:35 pm, Ross Mellgren dri...@gmail.com wrote:
   That's why I factored this as a JQueryNodeSeq, so you can pass anything
  to dialog (I've used JQuery, and figured you'd need to pass something in
  there ;-)

   JQueryNodeSeq(ns) ~ JsFunc(dialog, JsObj(autoOpen - JsTrue, width
  - 500, ..., close - AnonFunc(JsVal(this) ~ JsFunc(destroy

case class JQueryNodeSeq(ns: NodeSeq) extends JsExp with JQueryLeft
  with HtmlFixer {

   JsExp is the basic trait of the JavaScript DSL. Anything that can go into
  a JavaScript expression should have this trait.
   JQueryLeft is a trait used by the JQuery portion of the JavaScript DSL to
  indicate that you can chain JQuery calls onto this.
   HtmlFixer is a trait that provides fixHtml

   override def toJsCmd = jQuery( + JsStr(fixHtml(NodeSeqDialog,
  ns)).toJsCmd + )

   fixHtml takes the given NodeSeq and does all the appropriate magics to
  process lift: tags and then converts the NodeSeq to valid XHTML.

}

   And don't forget the security implications!

   Hope that helps,
   -Ross

   On Mar 9, 2010, at 12:30 PM, Stuart Roebuck wrote:

Thanks for that amazingly quick response!

I only wish I understood the proposed solution! :-)

So (confession time) I simplified things a little, the actual
JavaScript is…

var theDialog = $(…).dialog( { autoOpen: true, width: 500, modal:
true, close: function() { theDialog.destroy; }; } )

How do I assemble this, or is there any documentation / examples you
can point me to.

Thanks very much,

Stuart.

On Mar 9, 5:14 pm, Ross Mellgren dri...@gmail.com wrote:
Whoops, I meant Str(fixHtml(...)) not JsStr(fixHtml(...))

-Ross

On Mar 9, 2010, at 12:14 PM, Ross Mellgren wrote:

Try this (I haven't tested it, so there could be lurking bugs):

case class JQueryNodeSeq(ns: NodeSeq) extends JsExp with JQueryLeft
  with HtmlFixer {
   override def toJsCmd = jQuery( + JsStr(fixHtml(NodeSeqDialog,
  ns)).toJsCmd + )
}

Then JQueryNodeSeq(ns) ~ JsFunc(dialog)

-Ross

On Mar 9, 2010, at 12:06 PM, Stuart Roebuck wrote:

I'm trying to produce a web page with editable content.

When the user clicks an edit button on a line it uses jQuery to
display a modal dialog which allows fields of that line to be
  edited.

I can easily produce a snippet to produce the lines using the
  backend
data and an XHTML template and binding etc.

However, I also want the template to include the template for the
dialog.  So I want the ajax button callback to send JavaScript to
instantiate the jQuery UI dialog based on the template and bindings.

To build this I need to assemble a JsCmd containing the NodeSeq that
comes from the XHTML sequence and the bindings.

In short, if this was straight jQuery I would have some JavaScript
  of
the form:

$(div title=Dialog TitletheFormNodeSeq/div).dialog()

But in my case theFormNodeSeq comes from a NodeSeq that was
  assembled
from part of the XHTML template and the bindings and the end result
needs to be a JsCmd.

So I'm trying to do something like:

JsCmds.Run($( + theFormNodeSeq.toString + ).dialog())

But I need to address escaping issues with the HTML and I also need
  to
pre-process any lift:… / commands in theFormNodeSeq.

Any advice (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 athttp://
  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: New logging code is in master

2010-03-04 Thread Stuart Roebuck
Trying this on 2.8 with the 2.8 Lift Snapshot.

The Logger trait seems to work fine though looking at the code I can't
see how setup gets called.

The Loggable trait is throwing a null pointer exception.

I'm using Log4J.

Stuart.

P.S.  I don't want to mess with other people's wiki pages, but I
wonder whether it is worth consolidating the pages: How To: Configure
Logging and Logging in Lift.


On Mar 2, 12:49 am, aw anth...@whitford.com wrote:
 Very nice!  I am looking forward to this.

 On Feb 28, 8:14 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:



  The newloggingcode is now in master and should be fully usable.
  Therefore, the existingloggingcode has been deprecated.

  I've added a Wiki article 
  here:http://wiki.github.com/dpp/liftweb/logging-in-lift

  /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: Documenting the source code / supplementing the API docs

2010-02-26 Thread Stuart Roebuck
I've spoken to David off-
list and unfortunately I am not comfortable signing the particular IP assignment
contract I was sent as it appears to me (but not to David) to be ambiguous in whether it covers what I commit or also any other code I am working on in connection with Lift
(e.g. the code of my business).

I have offered to alter the wording but David has made it clear that
he will not move on the wording of this
and, as a lawyer, that it he knows what he is talking about better than I do.

Having previously contributed to Apache Ant, Apache Cocoon and Apache James as well as making various minor contributions and bug fixes to other open source projects I have never had a problem in the past with the wording of such agreements with
open source projects
and would happily of signed the type of agreement currently used by Apache. (http://
www.apache.org/licenses/icla.pdf)

Unfortunately it looks like my attempt to contribute some
documentation is at a dead
end!  Looking at the contract it is also clear that no other existing commiter may take my code or documentation and commit it, so thank you Ross for your offer, but it looks like that will not be possible.

As I have said to David -
 I really don't think that it should be so hard to accept contributions to this project.

Stuart.

As this contract is the one signed by all other commiters to the project, I am 

On Feb 23, 3:22 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
 The easiest thing is if Stuart signs an IP assignment, becomes a
 full-fledged committer and thus we keep the IP clean.

 Stuart, if you're interested in learning more, please contact me off-list.

 In terms of the documentation standards, I'm okay with anything that the
 rest of you-all want.  I'm neither the best producer or consumer of docs, so
 my voice is a small one on this issue, other than to give hearty thanks to
 those who write documentation.

 On Mon, Feb 22, 2010 at 1:05 PM, Stuart Roebuck 
 stuart.roeb...@gmail.comwrote:





  Great... okay, I’d better do some writing :-)

  In the absence of a decision I’ll try to minimise special coding in
  comments but use Scaladoc 2 standard if necessary rather than HTML as that
  makes it future proof but still readable for both.

  Stuart

  On 22 Feb 2010, at 17:32, Ross Mellgren wrote:

   I will do this, and give feed back if it ever becomes too much load.

   -Ross

   On Feb 22, 2010, at 12:05 PM, Timothy Perrett wrote:

   We are interested in the contribution of course... I think the issue is
  mostly about how we take patches for this. Someone on the team would need to
  own this and merge your documentation changes into the master (provided DPP
  has no objections to this - seeing as its documentation I doubt he has)

   Any takers from the team?

   Cheers, Tim

   On 22 Feb 2010, at 16:14, Stuart Roebuck wrote:

   Sorry for the slow response—was away for a family weekend!

   I have limited knowledge of Lift internals…

   However, my view is that it is often easier to document code when you
   don't know it well than when you do, because you soon loose interest
   in documenting things that are obvious to you.  What I hope to do is
   document the things that I need to know as I go along on the basis
   that many of these things will also be important to others.  It's an
   agile rather than systematic approach if you see what I mean.

   I have no ego issues here.  It's just a small way of giving to the
   community in a win-win kind of way.  If my contributions don't seem
   helpful to anyone else then folk can say and I'm not going to
   disappear in a torrent of abuse :-)

   Similarly, I'm not proposing some big project here. I'm talking about
   a drip-drip of updates as I spot things that need documenting—I've got
   plenty other stuff on my plate right now as I'm launching a company
   based on a Lift based product in mid-year.

   Enough said…

   How do we resolve the documentation standard issue? (Scala 2.8
   Scaladoc2 or prior)  David?

   Stuart.

   On Feb 19, 4:11 pm, Timothy Perrett timo...@getintheloop.eu wrote:
   This could work - although, some parts of lift are very non-trivial
  and require good knowledge of lift internals. Do you have such knowledge or
  are you just hoping to contribute where you can with helpful information?
  Both are good, just trying to establish what you had in mind.

   Lift-util probably has the best docs at the moment, so if we could
  emulate that it would be good.

   Cheers, Tim

   On 19 Feb 2010, at 15:56, Ross Mellgren wrote:

   If you can get an established standard on what the content and format
  should be, I can work with you reviewing the patches and applying them.

   But, need to get a concordance from the list on the content first.

   -Ross

   On Feb 19, 2010, at 10:53 AM, Stuart Roebuck wrote:

   I've had a bit of a break from Lift and coming back I find myself
   annoyed that I didn't write some notes last time and am having to go
   back

Re: [Lift] Re: Documenting the source code / supplementing the API docs

2010-02-26 Thread Stuart Roebuck
Tim,

Thanks - that sounds like a good idea.

Stuart.

On 26 Feb 2010, at 10:50, Timothy Perrett wrote:

 Stuart,
 
 You can still contribute to the wiki and of your findings or musings -
 that is totally open.
 
 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.



[Lift] Re: Documenting the source code / supplementing the API docs

2010-02-26 Thread Stuart Roebuck
Okay - I've added a page to the wiki:

  http://wiki.github.com/dpp/liftweb/sitemap-basics


On Feb 26, 11:20 am, Stuart Roebuck stuart.roeb...@gmail.com wrote:
 Tim,

 Thanks - that sounds like a good idea.

 Stuart.

 On 26 Feb 2010, at 10:50, Timothy Perrett wrote:



  Stuart,

  You can still contribute to the wiki and of your findings or musings -
  that is totally open.

  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.



[Lift] Re: Documenting the source code / supplementing the API docs

2010-02-22 Thread Stuart Roebuck
Sorry for the slow response—was away for a family weekend!

I have limited knowledge of Lift internals…

However, my view is that it is often easier to document code when you
don't know it well than when you do, because you soon loose interest
in documenting things that are obvious to you.  What I hope to do is
document the things that I need to know as I go along on the basis
that many of these things will also be important to others.  It's an
agile rather than systematic approach if you see what I mean.

I have no ego issues here.  It's just a small way of giving to the
community in a win-win kind of way.  If my contributions don't seem
helpful to anyone else then folk can say and I'm not going to
disappear in a torrent of abuse :-)

Similarly, I'm not proposing some big project here. I'm talking about
a drip-drip of updates as I spot things that need documenting—I've got
plenty other stuff on my plate right now as I'm launching a company
based on a Lift based product in mid-year.

Enough said…

How do we resolve the documentation standard issue? (Scala 2.8
Scaladoc2 or prior)  David?

Stuart.

On Feb 19, 4:11 pm, Timothy Perrett timo...@getintheloop.eu wrote:
 This could work - although, some parts of lift are very non-trivial and 
 require good knowledge of lift internals. Do you have such knowledge or are 
 you just hoping to contribute where you can with helpful information? Both 
 are good, just trying to establish what you had in mind.

 Lift-util probably has the best docs at the moment, so if we could emulate 
 that it would be good.

 Cheers, Tim

 On 19 Feb 2010, at 15:56, Ross Mellgren wrote:



  If you can get an established standard on what the content and format 
  should be, I can work with you reviewing the patches and applying them.

  But, need to get a concordance from the list on the content first.

  -Ross

  On Feb 19, 2010, at 10:53 AM, Stuart Roebuck wrote:

  I've had a bit of a break from Lift and coming back I find myself
  annoyed that I didn't write some notes last time and am having to go
  back to searching through the various bits of documentation to figure
  things out.

  Anyway, after much thought I decided that the best way to write my
  notes would be to supplement the API docs (ie. the Scaladoc
  documentation in the code base). so that I can view context sensitive
  help in my IDE of choice and others can benefit from my labours!

  So, question 1…

  The current API docs are very light on documentation and sometime ago
  I noticed some notice about removing documentation from the code
  base.   Is there some policy about not having documentation in the
  code or any thought on whether it should adhere to the Scaladoc 2
  syntax?

  Question 2…

  This is only really going to work if the process of submitting the
  documentation is reasonably straightforward so… What's the easiest
  possible way of submitting documentation changes to the code base? (if
  indeed this is something the core team would welcome).   I was
  thinking of perhaps emailing git patch files to someone in the core
  team who can verify that the comments are right before checking them
  in.  Any thoughts?

  If there is a reasonably explainable approach, it could be added as a
  Wiki page to encourage wider participation.

  Best,

  Stuart.

  --
  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 
  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.



Re: [Lift] Re: Documenting the source code / supplementing the API docs

2010-02-22 Thread Stuart Roebuck
Perhaps it's easier for me to do a fork on GitHub?  Then any documentation 
submissions can be taken across at a time that suits whoever is doing it rather 
than synced with my submission timeline?


On 22 Feb 2010, at 17:05, Timothy Perrett wrote:

 We are interested in the contribution of course... I think the issue is 
 mostly about how we take patches for this. Someone on the team would need to 
 own this and merge your documentation changes into the master (provided DPP 
 has no objections to this - seeing as its documentation I doubt he has) 
 
 Any takers from the team? 
 
 Cheers, Tim
 
 On 22 Feb 2010, at 16:14, Stuart Roebuck wrote:
 
 Sorry for the slow response—was away for a family weekend!
 
 I have limited knowledge of Lift internals…
 
 However, my view is that it is often easier to document code when you
 don't know it well than when you do, because you soon loose interest
 in documenting things that are obvious to you.  What I hope to do is
 document the things that I need to know as I go along on the basis
 that many of these things will also be important to others.  It's an
 agile rather than systematic approach if you see what I mean.
 
 I have no ego issues here.  It's just a small way of giving to the
 community in a win-win kind of way.  If my contributions don't seem
 helpful to anyone else then folk can say and I'm not going to
 disappear in a torrent of abuse :-)
 
 Similarly, I'm not proposing some big project here. I'm talking about
 a drip-drip of updates as I spot things that need documenting—I've got
 plenty other stuff on my plate right now as I'm launching a company
 based on a Lift based product in mid-year.
 
 Enough said…
 
 How do we resolve the documentation standard issue? (Scala 2.8
 Scaladoc2 or prior)  David?
 
 Stuart.
 
 On Feb 19, 4:11 pm, Timothy Perrett timo...@getintheloop.eu wrote:
 This could work - although, some parts of lift are very non-trivial and 
 require good knowledge of lift internals. Do you have such knowledge or are 
 you just hoping to contribute where you can with helpful information? Both 
 are good, just trying to establish what you had in mind.
 
 Lift-util probably has the best docs at the moment, so if we could emulate 
 that it would be good.
 
 Cheers, Tim
 
 On 19 Feb 2010, at 15:56, Ross Mellgren wrote:
 
 
 
 If you can get an established standard on what the content and format 
 should be, I can work with you reviewing the patches and applying them.
 
 But, need to get a concordance from the list on the content first.
 
 -Ross
 
 On Feb 19, 2010, at 10:53 AM, Stuart Roebuck wrote:
 
 I've had a bit of a break from Lift and coming back I find myself
 annoyed that I didn't write some notes last time and am having to go
 back to searching through the various bits of documentation to figure
 things out.
 
 Anyway, after much thought I decided that the best way to write my
 notes would be to supplement the API docs (ie. the Scaladoc
 documentation in the code base). so that I can view context sensitive
 help in my IDE of choice and others can benefit from my labours!
 
 So, question 1…
 
 The current API docs are very light on documentation and sometime ago
 I noticed some notice about removing documentation from the code
 base.   Is there some policy about not having documentation in the
 code or any thought on whether it should adhere to the Scaladoc 2
 syntax?
 
 Question 2…
 
 This is only really going to work if the process of submitting the
 documentation is reasonably straightforward so… What's the easiest
 possible way of submitting documentation changes to the code base? (if
 indeed this is something the core team would welcome).   I was
 thinking of perhaps emailing git patch files to someone in the core
 team who can verify that the comments are right before checking them
 in.  Any thoughts?
 
 If there is a reasonably explainable approach, it could be added as a
 Wiki page to encourage wider participation.
 
 Best,
 
 Stuart.
 
 --
 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 
 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.
 
 
 
 -- 
 You

Re: [Lift] Re: Documenting the source code / supplementing the API docs

2010-02-22 Thread Stuart Roebuck
Great... okay, I’d better do some writing :-)

In the absence of a decision I’ll try to minimise special coding in comments 
but use Scaladoc 2 standard if necessary rather than HTML as that makes it 
future proof but still readable for both.

Stuart

On 22 Feb 2010, at 17:32, Ross Mellgren wrote:

 I will do this, and give feed back if it ever becomes too much load.
 
 -Ross
 
 On Feb 22, 2010, at 12:05 PM, Timothy Perrett wrote:
 
 We are interested in the contribution of course... I think the issue is 
 mostly about how we take patches for this. Someone on the team would need to 
 own this and merge your documentation changes into the master (provided DPP 
 has no objections to this - seeing as its documentation I doubt he has) 
 
 Any takers from the team? 
 
 Cheers, Tim
 
 On 22 Feb 2010, at 16:14, Stuart Roebuck wrote:
 
 Sorry for the slow response—was away for a family weekend!
 
 I have limited knowledge of Lift internals…
 
 However, my view is that it is often easier to document code when you
 don't know it well than when you do, because you soon loose interest
 in documenting things that are obvious to you.  What I hope to do is
 document the things that I need to know as I go along on the basis
 that many of these things will also be important to others.  It's an
 agile rather than systematic approach if you see what I mean.
 
 I have no ego issues here.  It's just a small way of giving to the
 community in a win-win kind of way.  If my contributions don't seem
 helpful to anyone else then folk can say and I'm not going to
 disappear in a torrent of abuse :-)
 
 Similarly, I'm not proposing some big project here. I'm talking about
 a drip-drip of updates as I spot things that need documenting—I've got
 plenty other stuff on my plate right now as I'm launching a company
 based on a Lift based product in mid-year.
 
 Enough said…
 
 How do we resolve the documentation standard issue? (Scala 2.8
 Scaladoc2 or prior)  David?
 
 Stuart.
 
 On Feb 19, 4:11 pm, Timothy Perrett timo...@getintheloop.eu wrote:
 This could work - although, some parts of lift are very non-trivial and 
 require good knowledge of lift internals. Do you have such knowledge or 
 are you just hoping to contribute where you can with helpful information? 
 Both are good, just trying to establish what you had in mind.
 
 Lift-util probably has the best docs at the moment, so if we could emulate 
 that it would be good.
 
 Cheers, Tim
 
 On 19 Feb 2010, at 15:56, Ross Mellgren wrote:
 
 
 
 If you can get an established standard on what the content and format 
 should be, I can work with you reviewing the patches and applying them.
 
 But, need to get a concordance from the list on the content first.
 
 -Ross
 
 On Feb 19, 2010, at 10:53 AM, Stuart Roebuck wrote:
 
 I've had a bit of a break from Lift and coming back I find myself
 annoyed that I didn't write some notes last time and am having to go
 back to searching through the various bits of documentation to figure
 things out.
 
 Anyway, after much thought I decided that the best way to write my
 notes would be to supplement the API docs (ie. the Scaladoc
 documentation in the code base). so that I can view context sensitive
 help in my IDE of choice and others can benefit from my labours!
 
 So, question 1…
 
 The current API docs are very light on documentation and sometime ago
 I noticed some notice about removing documentation from the code
 base.   Is there some policy about not having documentation in the
 code or any thought on whether it should adhere to the Scaladoc 2
 syntax?
 
 Question 2…
 
 This is only really going to work if the process of submitting the
 documentation is reasonably straightforward so… What's the easiest
 possible way of submitting documentation changes to the code base? (if
 indeed this is something the core team would welcome).   I was
 thinking of perhaps emailing git patch files to someone in the core
 team who can verify that the comments are right before checking them
 in.  Any thoughts?
 
 If there is a reasonably explainable approach, it could be added as a
 Wiki page to encourage wider participation.
 
 Best,
 
 Stuart.
 
 --
 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 
 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

[Lift] Documenting the source code / supplementing the API docs

2010-02-19 Thread Stuart Roebuck
I've had a bit of a break from Lift and coming back I find myself
annoyed that I didn't write some notes last time and am having to go
back to searching through the various bits of documentation to figure
things out.

Anyway, after much thought I decided that the best way to write my
notes would be to supplement the API docs (ie. the Scaladoc
documentation in the code base). so that I can view context sensitive
help in my IDE of choice and others can benefit from my labours!

So, question 1…

The current API docs are very light on documentation and sometime ago
I noticed some notice about removing documentation from the code
base.   Is there some policy about not having documentation in the
code or any thought on whether it should adhere to the Scaladoc 2
syntax?

Question 2…

This is only really going to work if the process of submitting the
documentation is reasonably straightforward so… What's the easiest
possible way of submitting documentation changes to the code base? (if
indeed this is something the core team would welcome).   I was
thinking of perhaps emailing git patch files to someone in the core
team who can verify that the comments are right before checking them
in.  Any thoughts?

If there is a reasonably explainable approach, it could be added as a
Wiki page to encourage wider participation.

Best,

Stuart.

-- 
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: Scheduling the San Francisco Scala Lift Off

2010-01-13 Thread Stuart Roebuck
Or Edinburgh? :-)

On Jan 13, 12:22 pm, Mads Hartmann mads...@gmail.com wrote:
 Was is 'Scala Lift Off' ?
 I live in Denmark so i might be able to make it in either London or
 Norway :)

 On Jan 13, 12:32 pm, Miles Sabin mi...@milessabin.com wrote:



  On Wed, Jan 13, 2010 at 3:31 AM, David Pollak

  feeder.of.the.be...@gmail.com wrote:
   For the last two years, the San Francisco Scala Lift Off has happened the
   day after JavaOne.  It's looking like JavaOne might not happen this year, 
   so
   I'm starting to think about a time in the April-June timeframe when there
   are a lot of Scala and/or Java folks in San Francisco.  If you all have 
   any
   ideas of good dates, please post them.

  A bit early maybe, but EclipseCon 2010 is 22nd - 25th of March.

  Cheers,

  Miles

  --
  Miles Sabin
  tel: +44 (0)7813 944 528
  skype:  milessabinhttp://www.chuusai.com/http://twitter.com/milessabin
-- 
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: Removing Scala Actors from Lift

2009-09-30 Thread Stuart Roebuck

As someone coming in new I +1 to Derek’s vote.

Stuart.

On 30 Sep 2009, at 14:03, Derek Chen-Becker wrote:

 I would vote for naming the new module lift-common and renaming lift- 
 util to lift-webutil. It does mean some breakage but I think that  
 it's a clearer naming. lift-util and lift-common are just too close  
 for someone coming in new, IMHO.

 Derek

 On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote:

 2009/9/30 Josh Suereth joshua.suer...@gmail.com:
  As much as I agree with your decision, it just makes me sad.   I  
 know lots
  of people that learned scala for actors are the way of the  
 future I
  think we need to push harder.  Hopefully all major projects  
 migrating off
  actors will give EPFL a wake up call?

 This is the reason I created Akka, to have a standard platform for
 Actors with all the things one need to write production applications.
 Akka already have 4 committers and honestly, looking at the pace EPFL
 has had with bugfixing, features etc I think they will have a very
 hard time keep up with what the market needs. I have unfortunately
 given up up the Scala Actors library. I need the things Akka
 implements now and don't have time to wait indefinitely.

 
  - Josh
 
  On Tue, Sep 29, 2009 at 1:41 PM, David Pollak
  feeder.of.the.be...@gmail.com wrote:
 
 
  On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com 
 
  wrote:
 
  Apologies if I've missed something obvious but my web search  
 hasn't
  turned anything up...
 
  What are the Scala Actors instability issues? I'm in the process  
 of
  doing some major Scala development work and this comment raises
  concerns that I'd like to understand.
 
  The issues (with the Scala Actors in general and Lift's use of  
 them) are:
 
  Scala Actors use a custom version of Doug Leah's Fork/Join  
 library.  This
  was necessary for JDK 1.4 support.  With JDK 1.5, the  
 java.util.concurrent
  stuff should have been used.  I was led to understand that this  
 change was
  made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff  
 still
  contains fork-join.  The FJ library has a memory retention issue  
 where it
  trades memory for non-locking performance and, with many threads  
 in a
  thread-pool, this leads to out of memory issues.
  The Scala Actor code is very brittle.
   See 
  http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html
   The code has not been materially refactored, which means that  
 even in 2.8,
  there will be significant potential problems with the Actors.   
 Those
  potential problems have manifest themselves as real problems in  
 2.7.x.  I
  have spent in aggregate nearly 3 weeks of my time since November  
 2008
  working around the defects in the Actor library.  It's easier to  
 have our
  own Actors (the current Actor library is about 2 days of work on  
 my part and
  the refactoring of Lift to work with the existing Actor library  
 is another 2
  days of work.)
  EPFL has been generally slow to respond to bug reports.  I am very
  frustrated and quite frankly tired of having to cajole EPFL into  
 responding
  to defects in one of the premier Scala libraries.
 
  I would strongly suggest that you look at Akka.  It's got a  
 better view
  and implementation of Actors than does the standard Scala  
 distribution. Akka
  includes support for distributed actors, etc.
  Hope this helps.
 
 
  Best,
 
  Stuart
 
  On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com
  wrote:
   Folks,
  
   Given the continued instability of Scala Actors, I've decided  
 to remove
   them
   from Lift.
  
   Specifically, I'm migrating CometActors to sit on top of  
 Lift's Actors.
   But, you'll also be able to use Akka Actors to power Lift's
   CometActors.
   Specifically, I'm working with Jonas to make sure that we  
 share a
   common
   interface to Actors.
  
   I've gotten Lift nearly completely migrated over to Lift's  
 Actors on
   the
   dpp_wip_actorize branch.
Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize
  
   There will be some breaking changes to your applications.
Specifically:
  
  - Box will be moved to a new package, net.liftweb.base  
 (this is
   where the
  interface for Actors will live as well)
  - If you make any assumptions about your CometActors being  
 Scala
   Actors
  (e.g., using linking), you will have to rewrite this code
  - Some methods in Lift that currently take Scala Actors as
   parameters
  will take Lift Actors (e.g., ActorPing)
  
   There will be a parallel Maven repository with the new Lift  
 Actor stuff
   in
   it so you will be able to build you apps against the new code  
 before
   the
   official switch-over.
  
   Milestone 6 (which should be out next week) will be based on the
   existing
   Actor model.  After we get feedback from the community about  
 the new
   Actor
   stuff, we will switch -SNAPSHOT over to the new Actor stuff

[Lift] Re: Removing Scala Actors from Lift

2009-09-29 Thread Stuart Roebuck

Apologies if I've missed something obvious but my web search hasn't
turned anything up...

What are the Scala Actors instability issues? I'm in the process of
doing some major Scala development work and this comment raises
concerns that I'd like to understand.

Best,

Stuart

On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
 Folks,

 Given the continued instability of Scala Actors, I've decided to remove them
 from Lift.

 Specifically, I'm migrating CometActors to sit on top of Lift's Actors.
 But, you'll also be able to use Akka Actors to power Lift's CometActors.
 Specifically, I'm working with Jonas to make sure that we share a common
 interface to Actors.

 I've gotten Lift nearly completely migrated over to Lift's Actors on the
 dpp_wip_actorize branch.  
 Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize

 There will be some breaking changes to your applications.  Specifically:

    - Box will be moved to a new package, net.liftweb.base (this is where the
    interface for Actors will live as well)
    - If you make any assumptions about your CometActors being Scala Actors
    (e.g., using linking), you will have to rewrite this code
    - Some methods in Lift that currently take Scala Actors as parameters
    will take Lift Actors (e.g., ActorPing)

 There will be a parallel Maven repository with the new Lift Actor stuff in
 it so you will be able to build you apps against the new code before the
 official switch-over.

 Milestone 6 (which should be out next week) will be based on the existing
 Actor model.  After we get feedback from the community about the new Actor
 stuff, we will switch -SNAPSHOT over to the new Actor stuff.

 Questions, thoughts, or comments?

 Thanks,

 David

 --
 Lift, the simply functional web frameworkhttp://liftweb.net
 Beginning Scalahttp://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 liftweb@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: Removing Scala Actors from Lift

2009-09-29 Thread Stuart Roebuck

Okay, I think I've now found the reference I was looking for...

http://mail-archives.apache.org/mod_mbox/incubator-esme-dev/
200905.mbox/
%3ccdbebedf0905220957k7767c05emc0b6fb7812f1f...@mail.gmail.com%3e

Stuart.

On Sep 29, 10:35 am, Stuart Roebuck stuart.roeb...@gmail.com wrote:
 Apologies if I've missed something obvious but my web search hasn't
 turned anything up...

 What are the Scala Actors instability issues? I'm in the process of
 doing some major Scala development work and this comment raises
 concerns that I'd like to understand.

 Best,

 Stuart

 On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com
 wrote:



  Folks,

  Given the continued instability of Scala Actors, I've decided to remove them
  from Lift.

  Specifically, I'm migrating CometActors to sit on top of Lift's Actors.
  But, you'll also be able to use Akka Actors to power Lift's CometActors.
  Specifically, I'm working with Jonas to make sure that we share a common
  interface to Actors.

  I've gotten Lift nearly completely migrated over to Lift's Actors on the
  dpp_wip_actorize branch.  
  Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize

  There will be some breaking changes to your applications.  Specifically:

     - Box will be moved to a new package, net.liftweb.base (this is where the
     interface for Actors will live as well)
     - If you make any assumptions about your CometActors being Scala Actors
     (e.g., using linking), you will have to rewrite this code
     - Some methods in Lift that currently take Scala Actors as parameters
     will take Lift Actors (e.g., ActorPing)

  There will be a parallel Maven repository with the new Lift Actor stuff in
  it so you will be able to build you apps against the new code before the
  official switch-over.

  Milestone 6 (which should be out next week) will be based on the existing
  Actor model.  After we get feedback from the community about the new Actor
  stuff, we will switch -SNAPSHOT over to the new Actor stuff.

  Questions, thoughts, or comments?

  Thanks,

  David

  --
  Lift, the simply functional web frameworkhttp://liftweb.net
  Beginning Scalahttp://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 liftweb@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: 1.0.2 released

2009-09-11 Thread Stuart Roebuck

1.0.2 has certainly fixed the problem for me which I had encountered
in 1.0.1.

Stuart.

On Sep 11, 6:39 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
 Did you update your pom.xml file to set the lift version to 1.0.2?
 I just created a new project with 1.0.2 and it does not display this issue.





 On Thu, Sep 10, 2009 at 5:55 PM, DMB combust...@gmail.com wrote:

  You mean this guy? It's still there it seems.

  java.lang.NoSuchFieldException: refSet
         at java.lang.Class.getDeclaredField(Class.java:1882)
         at net.liftweb.http.PointlessActorToWorkAroundBug$$anonfun$act
  $2$$anonfun$apply$2.apply(LiftServlet.scala:722)
         at net.liftweb.http.PointlessActorToWorkAroundBug$$anonfun$act
  $2$$anonfun$apply$2.apply(LiftServlet.scala:714)
         at scala.actors.Reaction.run(Reaction.scala:78)
         at net.liftweb.http.ActorSchedulerFixer$$anon$1$$anon$3.run
  (LiftServlet.scala:673)
         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask
  (ThreadPoolExecutor.java:886)
         at java.util.concurrent.ThreadPoolExecutor$Worker.run
  (ThreadPoolExecutor.java:908)
         at java.lang.Thread.run(Thread.java:619)
  java.lang.NullPointerException
         at scala.runtime.BoxesRunTime.boxToInteger(Unknown Source)
         at scala.actors.Actor$$anonfun$scala$actors$Actor$$seq$1.apply
  (Actor.scala:800)
         at scala.actors.Actor$$anonfun$scala$actors$Actor$$seq$1.apply
  (Actor.scala:794)
         at scala.actors.Reaction.run(Reaction.scala:82)
         at net.liftweb.http.ActorSchedulerFixer$$anon$1$$anon$3.run
  (LiftServlet.scala:673)
         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask
  (ThreadPoolExecutor.java:886)
         at java.util.concurrent.ThreadPoolExecutor$Worker.run
  (ThreadPoolExecutor.java:908)
         at java.lang.Thread.run(Thread.java:619)

  On Sep 10, 2:03 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
   The Lift team is pleased to announce the lift-1.0.2 release!

   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.
   Lift is a scala web framework.

   Changes in this version include:

   Fixed Bugs:
   o Removed unnecessary fix for Actors issue now that we're on Scala 2.7.5

   Have fun!
   -Lift team

 --
 Lift, the simply functional web frameworkhttp://liftweb.net
 Beginning Scalahttp://www.apress.com/book/view/1430219890
 Follow me:http://twitter.com/dpp
 Git some:http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@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: Announcing 1.0.1!

2009-09-10 Thread Stuart Roebuck

I've switched a very simple test project from 1.0 to 1.0.1 and
switched the scala version to 2.7.5

Now I've started seeing the following in my jetty log:

ERROR - [MEMDEBUG] failure
java.lang.NoSuchFieldException: refSet
at java.lang.Class.getDeclaredField(Class.java:1882)
at net.liftweb.http.PointlessActorToWorkAroundBug$$anonfun$act$2$
$anonfun$apply$2.apply(LiftServlet.scala:722)
at net.liftweb.http.PointlessActorToWorkAroundBug$$anonfun$act$2$
$anonfun$apply$2.apply(LiftServlet.scala:714)
at scala.actors.Reaction.run(Reaction.scala:78)
at net.liftweb.http.ActorSchedulerFixer$$anon$1$$anon$3.run
(LiftServlet.scala:673)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask
(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:637)

I note that there is a reference to this on the mailing list some time
ago and this was attributed to being a Scala 2.7.5 issue.

?

Stuart

On Sep 9, 5:45 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
 Just a reminder for anyone out there who wants to use 1.0.1: you'll need to
 update your pom.xml to use Scala 2.7.5 (and match what Lift was built with).
 Typically this just means modifying the properties element in your pom.xml
 like so:

   properties
     scala.version2.7.5/scala.version
   /properties

 Derek

 On Wed, Sep 9, 2009 at 10:22 AM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:



  The Lift team is pleased to announce the lift-1.0.1 release!

  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.
  Lift is a scala web framework.

  Changes in this version include:

  New features:
  o Added custom type mapping to the DriverType class  Issue: 37.
  o Added MappedDate and MappedTime to allow for better specification of time
  data  Issue: 12.

  Fixed Bugs:
  o Backported fixes for the Textile and XML parsers
  o Backported the Actor memory leak fixes
  o Backported a fix to S.params
  o Fixed PostgreSQL Double type mapping
  o Fixed support for Oracle  Issue: 37.
  o Fixed MappedDateTime to use TIMESTAMP mapping  Issue: 12.
  o Fixed ResultSet stringification for NUMERIC and DECIMAL  Issue: 36.

  Changes:
  o Refactored generated key support in DB/Mapper  Issue: 37.
  o Modified DB Driver resolution to allow for version-specific drivers
  o Upgrade to Scala 2.7.5

  Have fun!
  -Lift team

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@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 1.1-SNAPSHOT under Scala 2.8 with NetBeans and the Scala plugin

2009-09-05 Thread Stuart Roebuck

David,

Thanks, that's very helpfully pulled me back from the abyss :-)

Stuart

On Sep 4, 11:28 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
 Lift does not yet compile under 2.8.

 I just had lunch with PaulP and will be working on a Lift branch that does
 work under 2.8, but it's going to be a little while before it all works (we
 need to get ScalaCheck working first and that's on one of Paul's branches).

 So, please use Lift with Scala 2.7.5.

 On Fri, Sep 4, 2009 at 3:26 PM, Stuart Roebuck 
 stuart.roeb...@gmail.comwrote:







  Being on the bleeding edge again, I'm trying to do some Lift stuff
  using the nice new Scala plugin for NetBeans.  However, this appears
  to require me to be working under the latest Scala 2.8 release.  So, I
  have downloaded the Lift sources and built 1.1-SNAPSHOT under Scala
  2.8.  Everything compiles fine but then I get this:

  net.liftweb.mapper.MetaMegaProtoUser does not take type parameters
  object User extends User with MetaMegaProtoUser[User] {

  Can anyone shed light on this and give any hints on how I resolve it.

  Consider me a Scala/Lift newbie.

 --
 Lift, the simply functional web frameworkhttp://liftweb.net
 Beginning Scalahttp://www.apress.com/book/view/1430219890
 Follow me:http://twitter.com/dpp
 Git some:http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@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] Lift 1.1-SNAPSHOT under Scala 2.8 with NetBeans and the Scala plugin

2009-09-04 Thread Stuart Roebuck

Being on the bleeding edge again, I'm trying to do some Lift stuff
using the nice new Scala plugin for NetBeans.  However, this appears
to require me to be working under the latest Scala 2.8 release.  So, I
have downloaded the Lift sources and built 1.1-SNAPSHOT under Scala
2.8.  Everything compiles fine but then I get this:

net.liftweb.mapper.MetaMegaProtoUser does not take type parameters
object User extends User with MetaMegaProtoUser[User] {

Can anyone shed light on this and give any hints on how I resolve it.

Consider me a Scala/Lift newbie.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@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
-~--~~~~--~~--~--~---