[Lift] Exception thrown in Firefox but not in IE. What Gives????

2009-04-11 Thread glenn

I'm getting concerned about the viability of a Lift/JQuery web
solution. I am trying to implement a widget around the
jquery.mbContainerPlus.1.7.6 plugin. I can get it to work in  IE 7,
but not in Firefox 3.08, where I get the following firebug error:

[Exception... Component returned failure code: 0x80004003
(NS_ERROR_INVALID_POINTER) [nsIDOMNSHTMLElement.innerHTML]  nsresult:
0x80004003 (NS_ERROR_INVALID_POINTER)  location: JS frame ::
http://localhost:8080/classpath/jquery-1.3.2.js :: anonymous :: line
251  data: no]
http://localhost:8080/classpath/jquery-1.3.2.js
Line 251

This has to do with an innerHtml line that shows up in jquery.js,
although line 251 in that file is actually blank, so I don't know
where it comes from.

Creating the widget was simple. I just created a class to spit out the
relevant NodeSeqs:

class Container {
  def renderHead(xhtml: NodeSeq): NodeSeq = {

head
  link rel=stylesheet type=text/css href={/ +
LiftRules.resourceServerPath +/mbContainer.css} title=style
media=screen/
  script type=text/javascript src={/ +
LiftRules.resourceServerPath + /mbContainer.js}/script
  script type=text/javascript src={/ +
LiftRules.resourceServerPath + /ui.core.min.js}/script
  script type=text/javascript src={/ +
LiftRules.resourceServerPath + /ui.draggable.min.js}/script
  script type=text/javascript src={/ +
LiftRules.resourceServerPath + /ui.resizable.min.js}/script
  script type=text/javascript src={/ +
LiftRules.resourceServerPath + /jquery.metadata.js}/
script
  script type=text/javascript{
Unparsed(
  $(function(){
$(.containerPlus).buildContainers({
containment:document,
elementsPath:elements/
});
});
)
   }
  /script
/head

  }


  def renderContainer(xhtml: NodeSeq): NodeSeq = {
  Unparsed(
  div class=containerPlus resizable {buttons:'m,c',
skin:'white'}
div class=no
div class=ne
div class=nmain content/div
/div
div class=o
div class=e
div class=c
div class=contentThis is 
the main content/div
/div
/div
/div
div
div class=so
   div class=se
  div class=s/div
   /div
 /div
/div
/div
 /div
  )
  }

If I have to jump through hoops to get it to work in Firefox, what
good is Lift? Or, am I just missing something obvious? If anyone has
had similar problems and has a workaround, please help.

By the way, if I just create an html file with the containerPlus node
as above and display it in Firefox without using Lift, I don't get the
error. Everything works great.

Glenn Silverman

--~--~-~--~~~---~--~~
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] maven lift-archtype 1.0 generators don't work with jetty version 7.0.0.

2009-04-11 Thread glenn

By the way, the maven lift-archetype-basic and blank ver 1.0 project
generators don't work with jetty versions greater than 6.1.16. The new
jetty 7.0.0 does not contain WebAppContext.class, which Lift requires.

Glenn Silverman

--~--~-~--~~~---~--~~
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] Scala and Lift/JavaFX code similarieties

2009-04-11 Thread glenn

Has anyone looked at JavaFX lately? Is there a common code base, or is
it just coincidence that it looks and behaves a lot like Scala?

Glenn Silverman

--~--~-~--~~~---~--~~
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: Build Comet applications using Scala, Lift, and jQuery

2009-04-11 Thread 刘浩
I am studying the Comet example from developerworks.
But encounter below problems.

I build the code with Lift 1.0 release

a. Compatible problem in AuctionActor.scala

 Line29  val button = button type=button{S.?(Bid Now!)}/button %
  (onclick - ajaxCall(JsRaw($('#newBid').attr('value')),
bid _))

It could not generate the onclick. I modified it as:
val button = button type=button{S.?(Bid Now!)}/button %
  (onclick - ajaxCall(JsRaw($('#newBid').attr('value')),
bid _)._2)

b. Seems a JQuery problem with FireFox(3.0.8)

I could not submit Bid after click Bid Now! button. But it works in IE8,
IE6.
Seems $('#newBid').attr('value') could not get correct value.

2009/3/27 etorreborre etorrebo...@gmail.com


 Anyone can comment the ServerSide article:
 http://www.theserverside.com/news/thread.tss?thread_id=54079?

 There are questions on accessibility and a template engine.

 Eric.
 


--~--~-~--~~~---~--~~
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: n00b question on code in Starting with Lift (and some feedback)

2009-04-11 Thread David Pollak
On Sat, Apr 11, 2009 at 6:18 AM, Antony Courtney
antony.court...@gmail.comwrote:


 I am an experienced Java / C++ / Haskell programmer, but new to Scala
 and Lift.  I've been learning Scala for a few weeks and am just
 starting to learn about Lift.  This question may show more about my
 ignorance of Scala that anything else, but I suspect I'm not alone so
 here goes...:

 In the code fragment for Show in Starting with Lift (as of March
 28, 2009; version 4?), section 2.6, bottom of page 14 on to page 15:
 What exactly are the functions 'bind', 'text' and 'select' here?
 Where are they defined and why are they in scope here? Where would I
 look in the API documentation to see the type signatures or understand
 in detail what these functions do? How would I be able to answer any
 of these questions on my own just by reading this code fragment?


In Scala, you can import an object (objects are singletons).  Importing an
object makes that object's methods available without specifying the object
to which they are attached.  This is similar to Java's static import.  So:

object Foo {
  def woof = Woof Woof
}

import Foo._

class Bar {
  println(My dog says +woof)
}


There are 3 main objects (singletons) that are used in Lift: S
(net.liftweb.http.S), SHtml (net.liftweb.http.SHtml), and
Helpers.(net.liftweb.util.Helpers).  You will find almost all the methods in
one of those places.  S is everything (not really) that is stateful (I named
it when I was using emacs and before I knew about importing objects and I
wanted something short to type.)  SHtml is also stateful and contains the
HTML creation for stateful stuff.  Helpers are a lot of methods that help
with stuff.  The methods text and select are in SHtml because they create
HTML and are stateful (they update the state in your application by creating
HTML elements that contain GUIDs that refer to functions on the server).
 The method bind is in Helpers.  Is helps you to re-write the incoming
XHTML.

In IntelliJ, I could control-click through from these methods right into the
Lift source for them.  I could not do this in NetBeans.

I hope this helps.

Thanks,

David





 I suspect the answer may involve implicit conversions or some other
 bits of Scala magic that I simply don't understand yet, so I beg your
 patience.  If possible, a few breadcrumbs to explain non-obvious bits
 of Scala the first time they are used might be helpful for Scala
 newcomers, even just as a footnote.

 Aside from all the meta-questions:  are these functions part of Lift
 or part of the Scala XML libs?   It might be worth mentioning what
 each of these functions do since they're pretty essential to
 understanding this code fragment and I think this is the first
 fragment in the doc that does something other than declare a class /
 table or deal with config stuff.

 -Antony

 



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: [scala] Google App Engine for Scala!

2009-04-11 Thread David Pollak
On Sat, Apr 11, 2009 at 12:53 AM, Atsuhiko Yamanaka 
atsuhiko.yaman...@gmail.com wrote:

 Hi,

 On Fri, Apr 10, 2009 at 10:03 PM, David Pollak
 feeder.of.the.be...@gmail.com wrote:
  Thank you! Thank you! Thank you!
  I'd like to kiss you (but my wife might get upset)
  Next time you come to the Bay Area, I will buy you lunch or dinner!

 If I get an opportunity to be there in the future, I'll want to enjoy
 lunch with you!


Cool.



 
  Here is a fork of liftweb source code to run lift-example on GAE/J,
   http://github.com/ymnk/liftweb/tree/master

 It seems that JDBC API must not have be forbidden on GAE/J .
 I have succeeded to use H2 mem db by updating to its latest version[1] and
 now DB functionalities have worked on
   http://lift-example.appspot.com/index

 However, it is not adequate for the practical usages, of course.
 FYI, I found an interesting message[2] about a plan to implement
 JDBC to com.google.appengine.api.datastore wrapper


GAE supports JPA and there's a lot of Lift JPA support... so maybe we can
update the example code to use JPA and we'll have persistence via BigTable.

In terms of Comet support (which relies on Actor support), I've got some
ideas on how to make the Actors always use the current thread which will
mean no spawning threads.  We'll also have to set the default Comet timeout
to 25 seconds as to not violate the GAE 30 second max request rule.

Fun stuff to do next week.

Thanks!

David




 PS. I will add CC to liftweb@googlegroups.com and further discussions
 should be there.

 [1] http://www.h2database.com/html/changelog.html
 [2]
 http://groups.google.com/group/google-appengine-java/msg/71278bbee901c652


 Sincerely,
 --
 Atsuhiko Yamanaka
 JCraft,Inc.
 1-14-20 HONCHO AOBA-KU,
 SENDAI, MIYAGI 980-0014 Japan.
 Tel +81-22-723-2150
   +1-415-578-3454
 Fax +81-22-224-8773
 Skype callto://jcraft/




-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: Scala and Lift/JavaFX code similarieties

2009-04-11 Thread David Pollak
On Fri, Apr 10, 2009 at 10:14 PM, glenn gl...@exmbly.com wrote:


 Has anyone looked at JavaFX lately? Is there a common code base, or is
 it just coincidence that it looks and behaves a lot like Scala?


No common code base that I know of.  Perhaps the JavaFX guys are just
borrowing great ideas from one of the best language designers around, Martin
Odersky.




 Glenn Silverman

 



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: Exception thrown in Firefox but not in IE. What Gives????

2009-04-11 Thread David Pollak
On Fri, Apr 10, 2009 at 9:49 PM, glenn gl...@exmbly.com wrote:


 I'm getting concerned about the viability of a Lift/JQuery web
 solution. I am trying to implement a widget around the
 jquery.mbContainerPlus.1.7.6 plugin. I can get it to work in  IE 7,
 but not in Firefox 3.08, where I get the following firebug error:

 [Exception... Component returned failure code: 0x80004003
 (NS_ERROR_INVALID_POINTER) [nsIDOMNSHTMLElement.innerHTML]  nsresult:
 0x80004003 (NS_ERROR_INVALID_POINTER)  location: JS frame ::
 http://localhost:8080/classpath/jquery-1.3.2.js :: anonymous :: line
 251  data: no]
 http://localhost:8080/classpath/jquery-1.3.2.js
 Line 251

 This has to do with an innerHtml line that shows up in jquery.js,
 although line 251 in that file is actually blank, so I don't know
 where it comes from.

 Creating the widget was simple. I just created a class to spit out the
 relevant NodeSeqs:

 class Container {
  def renderHead(xhtml: NodeSeq): NodeSeq = {

head
  link rel=stylesheet type=text/css href={/ +
 LiftRules.resourceServerPath +/mbContainer.css} title=style
 media=screen/
  script type=text/javascript src={/ +
 LiftRules.resourceServerPath + /mbContainer.js}/script
  script type=text/javascript src={/ +
 LiftRules.resourceServerPath + /ui.core.min.js}/script
  script type=text/javascript src={/ +
 LiftRules.resourceServerPath + /ui.draggable.min.js}/script
  script type=text/javascript src={/ +
 LiftRules.resourceServerPath + /ui.resizable.min.js}/script
  script type=text/javascript src={/ +
 LiftRules.resourceServerPath + /jquery.metadata.js}/
 script


This should be escaped in a ![CDATA[ block:



  script type=text/javascript{
Unparsed(
  $(function(){
$(.containerPlus).buildContainers({
containment:document,
elementsPath:elements/
});
});
)
   }
  /script
/head

  }


Why is this Unparsed?  Why not just use XML?



  def renderContainer(xhtml: NodeSeq): NodeSeq = {
  Unparsed(
  div class=containerPlus resizable {buttons:'m,c',
 skin:'white'}
div class=no
div class=ne
div class=nmain content/div
/div
div class=o
div class=e
div class=c
div class=contentThis is
 the main content/div
/div
/div
/div
div
div class=so
   div class=se
  div class=s/div
   /div
 /div
/div
/div
 /div
  )
  }

 If I have to jump through hoops to get it to work in Firefox, what
 good is Lift? Or, am I just missing something obvious? If anyone has
 had similar problems and has a workaround, please help.


The only problem I've ever had with Firefox is a bug related to attributes
with namespaces.

Please note that Lift serves XHTML and Firefox is very strict about
validating XHTML.  Unless you are serving your static page with a mime type
of application/xhtml+xml, you will not trigger Firefox's heightened
validation.




 By the way, if I just create an html file with the containerPlus node
 as above and display it in Firefox without using Lift, I don't get the
 error. Everything works great.

 Glenn Silverman

 



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: maven lift-archtype 1.0 generators don't work with jetty version 7.0.0.

2009-04-11 Thread David Pollak
On Fri, Apr 10, 2009 at 10:03 PM, glenn gl...@exmbly.com wrote:


 By the way, the maven lift-archetype-basic and blank ver 1.0 project
 generators don't work with jetty versions greater than 6.1.16. The new
 jetty 7.0.0 does not contain WebAppContext.class, which Lift requires.


Yes.  This is correct.




 Glenn Silverman

 



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: [scala] Google App Engine for Scala!

2009-04-11 Thread Atsuhiko Yamanaka

Hi,

On Sat, Apr 11, 2009 at 10:43 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
 GAE supports JPA and there's a lot of Lift JPA support... so maybe we can
 update the example code to use JPA and we'll have persistence via BigTable.

I may have missed something, but it seems that the combination of scala and
DataNucleus(used via JPA on GAE/J) does not work, as far as I have been trying.
Are there somebody who have succeeded to use scala and JPA on GAE/J?
Can we work around this problem by implementing entity classes in Java?

Sincerely,
--
Atsuhiko Yamanaka
JCraft,Inc.
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.
Tel +81-22-723-2150
 +1-415-578-3454
Fax +81-22-224-8773
Skype callto://jcraft/

--~--~-~--~~~---~--~~
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: Google App Engine for Scala!

2009-04-11 Thread walterc

cool, guys, looking forward to it, especially the current thread actor
bit.

On Apr 11, 9:43 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
 On Sat, Apr 11, 2009 at 12:53 AM, Atsuhiko Yamanaka 

 atsuhiko.yaman...@gmail.com wrote:
  Hi,

  On Fri, Apr 10, 2009 at 10:03 PM, David Pollak
  feeder.of.the.be...@gmail.com wrote:
   Thank you! Thank you! Thank you!
   I'd like to kiss you (but my wife might get upset)
   Next time you come to the Bay Area, I will buy you lunch or dinner!

  If I get an opportunity to be there in the future, I'll want to enjoy
  lunch with you!

 Cool.



   Here is a fork of liftweb source code to run lift-example on GAE/J,
    http://github.com/ymnk/liftweb/tree/master

  It seems that JDBC API must not have be forbidden on GAE/J .
  I have succeeded to use H2 mem db by updating to its latest version[1] and
  now DB functionalities have worked on
   http://lift-example.appspot.com/index

  However, it is not adequate for the practical usages, of course.
  FYI, I found an interesting message[2] about a plan to implement
  JDBC to com.google.appengine.api.datastore wrapper

 GAE supports JPA and there's a lot of Lift JPA support... so maybe we can
 update the example code to use JPA and we'll have persistence via BigTable.

 In terms of Comet support (which relies on Actor support), I've got some
 ideas on how to make the Actors always use the current thread which will
 mean no spawning threads.  We'll also have to set the default Comet timeout
 to 25 seconds as to not violate the GAE 30 second max request rule.

 Fun stuff to do next week.

 Thanks!

 David





  PS. I will add CC to liftweb@googlegroups.com and further discussions
  should be there.

  [1]http://www.h2database.com/html/changelog.html
  [2]
 http://groups.google.com/group/google-appengine-java/msg/71278bbee901...

  Sincerely,
  --
  Atsuhiko Yamanaka
  JCraft,Inc.
  1-14-20 HONCHO AOBA-KU,
  SENDAI, MIYAGI 980-0014 Japan.
  Tel +81-22-723-2150
    +1-415-578-3454
  Fax +81-22-224-8773
  Skype callto://jcraft/

 --
 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: [scala] Google App Engine for Scala!

2009-04-11 Thread João Pereira
Hi,

I'm trying to have a simple lift app running on GAE.
The app is generated from the archetype-blank

I can deploy it on GAE, but I'm getting :

Failed LiftFilter

java.lang.NoClassDefFoundError: java.net.InetAddress is a restricted
class. Please see the Google App Engine developer's guide for more
details.


When running the app on GAE

What do I need to have a simple lift app running on GAE?

A newbie,

On Sat, Apr 11, 2009 at 2:43 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:



 On Sat, Apr 11, 2009 at 12:53 AM, Atsuhiko Yamanaka 
 atsuhiko.yaman...@gmail.com wrote:

 Hi,

 On Fri, Apr 10, 2009 at 10:03 PM, David Pollak
 feeder.of.the.be...@gmail.com wrote:
  Thank you! Thank you! Thank you!
  I'd like to kiss you (but my wife might get upset)
  Next time you come to the Bay Area, I will buy you lunch or dinner!

 If I get an opportunity to be there in the future, I'll want to enjoy
 lunch with you!


 Cool.



 
  Here is a fork of liftweb source code to run lift-example on GAE/J,
   http://github.com/ymnk/liftweb/tree/master

 It seems that JDBC API must not have be forbidden on GAE/J .
 I have succeeded to use H2 mem db by updating to its latest version[1] and
 now DB functionalities have worked on
   http://lift-example.appspot.com/index

 However, it is not adequate for the practical usages, of course.
 FYI, I found an interesting message[2] about a plan to implement
 JDBC to com.google.appengine.api.datastore wrapper


 GAE supports JPA and there's a lot of Lift JPA support... so maybe we can
 update the example code to use JPA and we'll have persistence via BigTable.

 In terms of Comet support (which relies on Actor support), I've got some
 ideas on how to make the Actors always use the current thread which will
 mean no spawning threads.  We'll also have to set the default Comet timeout
 to 25 seconds as to not violate the GAE 30 second max request rule.

 Fun stuff to do next week.

 Thanks!

 David




 PS. I will add CC to liftweb@googlegroups.com and further discussions
 should be there.

 [1] http://www.h2database.com/html/changelog.html
 [2]
 http://groups.google.com/group/google-appengine-java/msg/71278bbee901c652


 Sincerely,
 --
 Atsuhiko Yamanaka
 JCraft,Inc.
 1-14-20 HONCHO AOBA-KU,
 SENDAI, MIYAGI 980-0014 Japan.
 Tel +81-22-723-2150
   +1-415-578-3454
 Fax +81-22-224-8773
 Skype callto://jcraft/




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


 



-- 
João Miguel Pereira, PMP
http://jpereira.eu
http://www.linkedin.com/in/joaomiguelpereira
joaomiguel.pere...@gmail.com
(351) 96 275 68 58

--~--~-~--~~~---~--~~
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: n00b question on code in Starting with Lift (and some feedback)

2009-04-11 Thread David Pollak
On Sat, Apr 11, 2009 at 7:32 AM, Antony Courtney
antony.court...@gmail.comwrote:


 Thanks, David, that is tremendously helpful.  Clearly I was just
 missing the object import.

 While Starting with Lift shouldn't be a Scala tutorial, I think it
 would be quite helpful in this case to mention which objects provide
 these particular methods and maybe even mention the object import and
 show the import SHtml._ line in the fragment.


The biggest complaint about my book (Beginning Scala) is that it doesn't
cover enough Lift.  It seems that the Lift intros don't cover enough
Scala... at some point we'll find the right balance. :-)

Thanks for your feedback and I look forward to a lot more!

David




-Antony

 On Sat, Apr 11, 2009 at 9:40 AM, David Pollak
 feeder.of.the.be...@gmail.com wrote:
 
 
  On Sat, Apr 11, 2009 at 6:18 AM, Antony Courtney 
 antony.court...@gmail.com
  wrote:
 
  I am an experienced Java / C++ / Haskell programmer, but new to Scala
  and Lift.  I've been learning Scala for a few weeks and am just
  starting to learn about Lift.  This question may show more about my
  ignorance of Scala that anything else, but I suspect I'm not alone so
  here goes...:
 
  In the code fragment for Show in Starting with Lift (as of March
  28, 2009; version 4?), section 2.6, bottom of page 14 on to page 15:
  What exactly are the functions 'bind', 'text' and 'select' here?
  Where are they defined and why are they in scope here? Where would I
  look in the API documentation to see the type signatures or understand
  in detail what these functions do? How would I be able to answer any
  of these questions on my own just by reading this code fragment?
 
  In Scala, you can import an object (objects are singletons).  Importing
 an
  object makes that object's methods available without specifying the
 object
  to which they are attached.  This is similar to Java's static import.
  So:
 
  object Foo {
def woof = Woof Woof
  }
 
  import Foo._
 
  class Bar {
println(My dog says +woof)
  }
 
  There are 3 main objects (singletons) that are used in Lift: S
  (net.liftweb.http.S), SHtml (net.liftweb.http.SHtml), and
  Helpers.(net.liftweb.util.Helpers).  You will find almost all the methods
 in
  one of those places.  S is everything (not really) that is stateful (I
 named
  it when I was using emacs and before I knew about importing objects and I
  wanted something short to type.)  SHtml is also stateful and contains the
  HTML creation for stateful stuff.  Helpers are a lot of methods that help
  with stuff.  The methods text and select are in SHtml because they create
  HTML and are stateful (they update the state in your application by
 creating
  HTML elements that contain GUIDs that refer to functions on the server).
   The method bind is in Helpers.  Is helps you to re-write the incoming
  XHTML.
  In IntelliJ, I could control-click through from these methods right into
 the
  Lift source for them.  I could not do this in NetBeans.
  I hope this helps.
  Thanks,
  David
 
 
 
 
  I suspect the answer may involve implicit conversions or some other
  bits of Scala magic that I simply don't understand yet, so I beg your
  patience.  If possible, a few breadcrumbs to explain non-obvious bits
  of Scala the first time they are used might be helpful for Scala
  newcomers, even just as a footnote.
 
  Aside from all the meta-questions:  are these functions part of Lift
  or part of the Scala XML libs?   It might be worth mentioning what
  each of these functions do since they're pretty essential to
  understanding this code fragment and I think this is the first
  fragment in the doc that does something other than declare a class /
  table or deal with config stuff.
 
  -Antony
 
 
 
 
 
  --
  Lift, the simply functional web framework http://liftweb.net
  Beginning Scala http://www.apress.com/book/view/1430219890
  Follow me: http://twitter.com/dpp
  Git some: http://github.com/dpp
 
  
 

 



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: Exception thrown in Firefox but not in IE. What Gives????

2009-04-11 Thread glenn

Dave,

I appreciate your input. I've tried many permutations of code to try
to get this to work. The ![CDATA[ block didn;t work. I even just put
all the code into default.html as-is - no widget at all, no special
parsing involved, and still no luck.

I did get rid of the Firefox error by removing the unparsed stuff.
However, the code still doesn't work because I think it can't find the
elementsPath
 elements/. In fact, now it doesn't even work in IE.

This path contains all the images used by the container. I've placed
them in src\main\webapp\elements. Do
I also need to manage this somehow in Boot with ResourceServer.allow
and/or put the images someplace else?

The strange thing is that when I was getting the Firefox error, the
container images worked fine in IE. So it seemed the elementsPath was
OK.
This leads me to believe there is some parsing going on in Lift that I
just don't grasp. But, then again, it's probably something simple.

Glenn Silverman


On Apr 11, 6:53 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
 On Fri, Apr 10, 2009 at 9:49 PM, glenn gl...@exmbly.com wrote:

  I'm getting concerned about the viability of a Lift/JQuery web
  solution. I am trying to implement a widget around the
  jquery.mbContainerPlus.1.7.6 plugin. I can get it to work in  IE 7,
  but not in Firefox 3.08, where I get the following firebug error:

  [Exception... Component returned failure code: 0x80004003
  (NS_ERROR_INVALID_POINTER) [nsIDOMNSHTMLElement.innerHTML]  nsresult:
  0x80004003 (NS_ERROR_INVALID_POINTER)  location: JS frame ::
 http://localhost:8080/classpath/jquery-1.3.2.js:: anonymous :: line
  251  data: no]
 http://localhost:8080/classpath/jquery-1.3.2.js
  Line 251

  This has to do with an innerHtml line that shows up in jquery.js,
  although line 251 in that file is actually blank, so I don't know
  where it comes from.

  Creating the widget was simple. I just created a class to spit out the
  relevant NodeSeqs:

  class Container {
   def renderHead(xhtml: NodeSeq): NodeSeq = {

     head
       link rel=stylesheet type=text/css href={/ +
  LiftRules.resourceServerPath +/mbContainer.css} title=style
  media=screen/
       script type=text/javascript src={/ +
  LiftRules.resourceServerPath + /mbContainer.js}/script
       script type=text/javascript src={/ +
  LiftRules.resourceServerPath + /ui.core.min.js}/script
       script type=text/javascript src={/ +
  LiftRules.resourceServerPath + /ui.draggable.min.js}/script
       script type=text/javascript src={/ +
  LiftRules.resourceServerPath + /ui.resizable.min.js}/script
       script type=text/javascript src={/ +
  LiftRules.resourceServerPath + /jquery.metadata.js}/
  script

 This should be escaped in a ![CDATA[ block:





       script type=text/javascript{
         Unparsed(
           $(function(){
                         $(.containerPlus).buildContainers({
                                 containment:document,
                                 elementsPath:elements/
                         });
                 });
         )
        }
       /script
     /head

   }

 Why is this Unparsed?  Why not just use XML?





   def renderContainer(xhtml: NodeSeq): NodeSeq = {
       Unparsed(
       div class=containerPlus resizable {buttons:'m,c',
  skin:'white'}
                 div class=no
                         div class=ne
                                 div class=nmain content/div
                         /div
                         div class=o
                                 div class=e
                                         div class=c
                                                 div class=contentThis is
  the main content/div
                                         /div
                                 /div
                         /div
                         div
                         div class=so
                                div class=se
                                       div class=s/div
                                    /div
                                  /div
                     /div
                 /div
      /div
       )
   }

  If I have to jump through hoops to get it to work in Firefox, what
  good is Lift? Or, am I just missing something obvious? If anyone has
  had similar problems and has a workaround, please help.

 The only problem I've ever had with Firefox is a bug related to attributes
 with namespaces.

 Please note that Lift serves XHTML and Firefox is very strict about
 validating XHTML.  Unless you are serving your static page with a mime type
 of application/xhtml+xml, you will not trigger Firefox's heightened
 validation.



  By the way, if I just create an html file with the containerPlus node
  as above and display it in Firefox without using Lift, I don't get the
  error. Everything works great.

  Glenn Silverman

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

[Lift] Re: Exception thrown in Firefox but not in IE. What Gives????

2009-04-11 Thread David Pollak
Please post a simple example that fails on Firefox.  I'll clean it up for
you.

On Sat, Apr 11, 2009 at 11:42 AM, glenn gl...@exmbly.com wrote:


 Dave,

 I appreciate your input. I've tried many permutations of code to try
 to get this to work. The ![CDATA[ block didn;t work. I even just put
 all the code into default.html as-is - no widget at all, no special
 parsing involved, and still no luck.

 I did get rid of the Firefox error by removing the unparsed stuff.
 However, the code still doesn't work because I think it can't find the
 elementsPath
  elements/. In fact, now it doesn't even work in IE.

 This path contains all the images used by the container. I've placed
 them in src\main\webapp\elements. Do
 I also need to manage this somehow in Boot with ResourceServer.allow
 and/or put the images someplace else?

 The strange thing is that when I was getting the Firefox error, the
 container images worked fine in IE. So it seemed the elementsPath was
 OK.
 This leads me to believe there is some parsing going on in Lift that I
 just don't grasp. But, then again, it's probably something simple.

 Glenn Silverman


 On Apr 11, 6:53 am, David Pollak feeder.of.the.be...@gmail.com
 wrote:
  On Fri, Apr 10, 2009 at 9:49 PM, glenn gl...@exmbly.com wrote:
 
   I'm getting concerned about the viability of a Lift/JQuery web
   solution. I am trying to implement a widget around the
   jquery.mbContainerPlus.1.7.6 plugin. I can get it to work in  IE 7,
   but not in Firefox 3.08, where I get the following firebug error:
 
   [Exception... Component returned failure code: 0x80004003
   (NS_ERROR_INVALID_POINTER) [nsIDOMNSHTMLElement.innerHTML]  nsresult:
   0x80004003 (NS_ERROR_INVALID_POINTER)  location: JS frame ::
  http://localhost:8080/classpath/jquery-1.3.2.js:: anonymous :: line
   251  data: no]
  http://localhost:8080/classpath/jquery-1.3.2.js
   Line 251
 
   This has to do with an innerHtml line that shows up in jquery.js,
   although line 251 in that file is actually blank, so I don't know
   where it comes from.
 
   Creating the widget was simple. I just created a class to spit out the
   relevant NodeSeqs:
 
   class Container {
def renderHead(xhtml: NodeSeq): NodeSeq = {
 
  head
link rel=stylesheet type=text/css href={/ +
   LiftRules.resourceServerPath +/mbContainer.css} title=style
   media=screen/
script type=text/javascript src={/ +
   LiftRules.resourceServerPath + /mbContainer.js}/script
script type=text/javascript src={/ +
   LiftRules.resourceServerPath + /ui.core.min.js}/script
script type=text/javascript src={/ +
   LiftRules.resourceServerPath + /ui.draggable.min.js}/script
script type=text/javascript src={/ +
   LiftRules.resourceServerPath + /ui.resizable.min.js}/script
script type=text/javascript src={/ +
   LiftRules.resourceServerPath + /jquery.metadata.js}/
   script
 
  This should be escaped in a ![CDATA[ block:
 
 
 
 
 
script type=text/javascript{
  Unparsed(
$(function(){
  $(.containerPlus).buildContainers({
  containment:document,
  elementsPath:elements/
  });
  });
  )
 }
/script
  /head
 
}
 
  Why is this Unparsed?  Why not just use XML?
 
 
 
 
 
def renderContainer(xhtml: NodeSeq): NodeSeq = {
Unparsed(
div class=containerPlus resizable {buttons:'m,c',
   skin:'white'}
  div class=no
  div class=ne
  div class=nmain content/div
  /div
  div class=o
  div class=e
  div class=c
  div
 class=contentThis is
   the main content/div
  /div
  /div
  /div
  div
  div class=so
 div class=se
div class=s/div
 /div
   /div
  /div
  /div
   /div
)
}
 
   If I have to jump through hoops to get it to work in Firefox, what
   good is Lift? Or, am I just missing something obvious? If anyone has
   had similar problems and has a workaround, please help.
 
  The only problem I've ever had with Firefox is a bug related to
 attributes
  with namespaces.
 
  Please note that Lift serves XHTML and Firefox is very strict about
  validating XHTML.  Unless you are serving your static page with a mime
 type
  of application/xhtml+xml, you will not trigger Firefox's heightened
  validation.
 
 
 
   By the way, if I just create an html file with the containerPlus node
   

[Lift] Re: TemplateCache

2009-04-11 Thread marius d.

I just committed a SoftReferenceCache implementation in utils and it
is used by InMemoryCache. So far testing it looks pretty good. The
point of a SoftReferenceMap is probably obvious to prevent (as much as
possible) OOME. This is fine IMHO cause it's more important to have
the application running an not crash due to large potentially large
caches. Of course if a cache template is gc-ed it will be re-cached on
the subsequent attempt to use it.

I would appreciate any early feedback.

Br's,
Marius

On Apr 6, 1:00 am, Derek Chen-Becker dchenbec...@gmail.com wrote:
 I agree. Thread safety would be nice, and should be easily achievable with
 some existing code. The beauty of traits is that we can get these orthogonal
 behaviors through composition.

 Derek

 On Sun, Apr 5, 2009 at 2:21 PM, Timothy Perrett 
 timo...@getintheloop.euwrote:



  Just taken a look over the code - looks pretty cool!

  I like your ideas for ConcurrentHashMap - all sounds pretty awesome...
  regarding the use of EHCache, I rekon as long as provide a hook
  mechinism into the cache system, then sure, we should let people worry
  about those issues in there specific implementation as 90% of users
  simply wont need that functionality IMO.

  Cheers, Tim

  On Apr 5, 8:53 pm, Timothy Perrett timo...@getintheloop.eu wrote:
   Wow, derek you must be watching Github like a hawk haha ;-)

   Just to bring an off list convo between myself and Marius onto the list,
  are
   we looking at having some generic caching infrastructure in lift? This
  would
   be great re the localization / translation stuff im working on which
   currently uses KeyedCache in lift-util as a base.

   Im just doing a git pull for the cache branch...

   Cheers

   Tim

   On 05/04/2009 20:38, marius d. marius.dan...@gmail.com wrote:

Good :) ... I was also thinking on a flush-able caching mechanism. So
far the InMemoryCache is more for exemplification as it is not yet
thread safe. It is based on LRU cache but I'm also thinking to also
combine the ConcurrentHashMap approach with LRU ... also I was
thinking to a SoftReference map (as I implemented this once in Java)
but we'll see. It's evolving. I'm not sure at all if we should use
EHCahe or JBossCahe like solutions as we don't really need distributed
caching. Basides if people will want this they can just plugin their
own caching mechanisms.

Br's,
Marius

On Apr 5, 10:24 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
I just saw the commit from Marius on a preliminary template cache and
  it
looks good. I was thinking the same thing in terms of where and how to
  hook
it. I think that there are some possibilities for some more
  functionality on
the TemplateCache trait, including a programmatic flush (in case
  you're
pushing new template files in production and want to force
  re-fetching, for
instance), but I like the basic concept.

Derek
--~--~-~--~~~---~--~~
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: TemplateCache

2009-04-11 Thread marius d.

I committed it of course in wip-marius-template-cache branch.

On Apr 11, 11:16 pm, marius d. marius.dan...@gmail.com wrote:
 I just committed a SoftReferenceCache implementation in utils and it
 is used by InMemoryCache. So far testing it looks pretty good. The
 point of a SoftReferenceMap is probably obvious to prevent (as much as
 possible) OOME. This is fine IMHO cause it's more important to have
 the application running an not crash due to large potentially large
 caches. Of course if a cache template is gc-ed it will be re-cached on
 the subsequent attempt to use it.

 I would appreciate any early feedback.

 Br's,
 Marius

 On Apr 6, 1:00 am, Derek Chen-Becker dchenbec...@gmail.com wrote:

  I agree. Thread safety would be nice, and should be easily achievable with
  some existing code. The beauty of traits is that we can get these orthogonal
  behaviors through composition.

  Derek

  On Sun, Apr 5, 2009 at 2:21 PM, Timothy Perrett 
  timo...@getintheloop.euwrote:

   Just taken a look over the code - looks pretty cool!

   I like your ideas for ConcurrentHashMap - all sounds pretty awesome...
   regarding the use of EHCache, I rekon as long as provide a hook
   mechinism into the cache system, then sure, we should let people worry
   about those issues in there specific implementation as 90% of users
   simply wont need that functionality IMO.

   Cheers, Tim

   On Apr 5, 8:53 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Wow, derek you must be watching Github like a hawk haha ;-)

Just to bring an off list convo between myself and Marius onto the list,
   are
we looking at having some generic caching infrastructure in lift? This
   would
be great re the localization / translation stuff im working on which
currently uses KeyedCache in lift-util as a base.

Im just doing a git pull for the cache branch...

Cheers

Tim

On 05/04/2009 20:38, marius d. marius.dan...@gmail.com wrote:

 Good :) ... I was also thinking on a flush-able caching mechanism. So
 far the InMemoryCache is more for exemplification as it is not yet
 thread safe. It is based on LRU cache but I'm also thinking to also
 combine the ConcurrentHashMap approach with LRU ... also I was
 thinking to a SoftReference map (as I implemented this once in Java)
 but we'll see. It's evolving. I'm not sure at all if we should use
 EHCahe or JBossCahe like solutions as we don't really need distributed
 caching. Basides if people will want this they can just plugin their
 own caching mechanisms.

 Br's,
 Marius

 On Apr 5, 10:24 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
 I just saw the commit from Marius on a preliminary template cache and
   it
 looks good. I was thinking the same thing in terms of where and how 
 to
   hook
 it. I think that there are some possibilities for some more
   functionality on
 the TemplateCache trait, including a programmatic flush (in case
   you're
 pushing new template files in production and want to force
   re-fetching, for
 instance), but I like the basic concept.

 Derek
--~--~-~--~~~---~--~~
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 helloworld on App Engine: java.lang.NoClassDefFoundError: Could not initialize class net.liftweb.http.LiftRules$

2009-04-11 Thread David Pollak
See this fork of Lift:http://github.com/ymnk/liftweb/tree/master

We'll roll the changes into 1.1-SNAPSHOT next week.

On Sat, Apr 11, 2009 at 6:18 PM, Dave Briccetti da...@davebsoft.com wrote:


 Hi. Should this be working now, or are we waiting for code changes?


   1. ...

   2.
  W 04-11 06:09PM 30.161

  failed LiftFilter
  java.lang.NoClassDefFoundError: Could not initialize class
 net.liftweb.http.LiftRules$
at net.liftweb.http.LiftFilter.init(LiftServlet.scala:546)
at org.mortbay.jetty.servlet.FilterHolder.doStart
 (FilterHolder.java:99)
at org.mortbay.component.AbstractLifeCycle.start
 (AbstractLifeCycle.java:40)
at org.mortbay.jetty.servlet.ServletHandler.initialize
 (ServletHandler.java:589)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:
 139)
at org.mortbay.jetty.webapp.WebAppContext.startContext
 (WebAppContext.java:1218)
at org.mortbay.jetty.handler.ContextHandler.doStart
 (ContextHandler.java:500)
at org.mortbay.jetty.webapp.WebAppContext.doStart
 (WebAppContext.java:448)
at org.mortbay.component.AbstractLifeCycle.start
 (AbstractLifeCycle.java:40)
at
 com.google.apphosting.runtime.jetty.AppVersionHandlerMap.createHandler
 (AppVersionHandlerMap.java:190)
at
 com.google.apphosting.runtime.jetty.AppVersionHandlerMap.getHandler
 (AppVersionHandlerMap.java:167)
at

 com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest
 (JettyServletEngineAdapter.java:113)
at com.google.apphosting.runtime.JavaRuntime.handleRequest
 (JavaRuntime.java:235)
at com.google.apphosting.base.RuntimePb$EvaluationRuntime
 $6.handleBlockingRequest(RuntimePb.java:4547)
at com.google.apphosting.base.RuntimePb$EvaluationRuntime
 $6.handleBlockingRequest(RuntimePb.java:4545)
at
 com.google.net.rpc.impl.BlockingApplicationHandler.handleRequest
 (BlockingApplicationHandler.java:24)
at com.google.net.rpc.impl.RpcUtil.runRpcInApplication
 (RpcUtil.java:359)
at com.google.net.rpc.impl.Server$2.run(Server.java:792)
at com.google.tracing.LocalTraceSpanRunnable.run
 (LocalTraceSpanRunnable.java:56)
at com.google.tracing.LocalTraceSpanBuilder.internalContinueSpan
 (LocalTraceSpanBuilder.java:489)
at com.google.net.rpc.impl.Server.startRpc(Server.java:748)
at com.google.net.rpc.impl.Server.processRequest(Server.java:
 340)
at com.google.net.rpc.impl.ServerConnection.messageReceived
 (ServerConnection.java:422)
at com.google.net.rpc.impl.RpcConnection.parseMessages
 (RpcConnection.java:319)
at com.google.net.rpc.impl.RpcConnection.dataReceived
 (RpcConnection.java:290)
at com.google.net.async.Connection.handleReadEvent
 (Connection.java:419)
at com.google.net.async.EventDispatcher.processNetworkEvents
 (EventDispatcher.java:733)
at com.google.net.async.EventDispatcher.internalLoop
 (EventDispatcher.java:207)
at com.google.net.async.EventDispatcher.loop
 (EventDispatcher.java:101)
at com.google.net.rpc.RpcService.runUntilServerShutdown
 (RpcService.java:249)
at com.google.apphosting.runtime.JavaRuntime$RpcRunnable.run
 (JavaRuntime.java:373)
at java.lang.Thread.run(Unknown Source)

   3.
  W 04-11 06:09PM 30.162

  failed
 com.google.apphosting.utils.jetty.runtimeappenginewebappcont...@1ef3a22
 {/,/base/data/home/apps/simple-twitter-client/
 experimental-3.332725327646020693}
  java.lang.NoClassDefFoundError: Could not initialize class
 net.liftweb.http.LiftRules$
at net.liftweb.http.LiftFilter.init(LiftServlet.scala:546)
at org.mortbay.jetty.servlet.FilterHolder.doStart
 (FilterHolder.java:99)
at org.mortbay.component.AbstractLifeCycle.start
 (AbstractLifeCycle.java:40)
at org.mortbay.jetty.servlet.ServletHandler.initialize
 (ServletHandler.java:589)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:
 139)
at org.mortbay.jetty.webapp.WebAppContext.startContext
 (WebAppContext.java:1218)
at org.mortbay.jetty.handler.ContextHandler.doStart
 (ContextHandler.java:500)
at org.mortbay.jetty.webapp.WebAppContext.doStart
 (WebAppContext.java:448)
at org.mortbay.component.AbstractLifeCycle.start
 (AbstractLifeCycle.java:40)
at
 com.google.apphosting.runtime.jetty.AppVersionHandlerMap.createHandler
 (AppVersionHandlerMap.java:190)
at
 com.google.apphosting.runtime.jetty.AppVersionHandlerMap.getHandler
 (AppVersionHandlerMap.java:167)
at

 com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest
 (JettyServletEngineAdapter.java:113)
at com.google.apphosting.runtime.JavaRuntime.handleRequest
 (JavaRuntime.java:235)
at com.google.apphosting.base.RuntimePb$EvaluationRuntime
 $6.handleBlockingRequest(RuntimePb.java:4547)
at com.google.apphosting.base.RuntimePb$EvaluationRuntime
 

[Lift] Re: stateful vs stateless snippet

2009-04-11 Thread Oliver Lambert
On Sun, Apr 12, 2009 at 7:14 AM, marius d. marius.dan...@gmail.com wrote:


 The StatefulSnippet is not a snippet instance that is always used in
 the context of your session.


Yikes! in that case, I wrote a whole application based on false assumption.
It says in the lift book
a StatefulSnippet is ideal for small, conversational state, such as a form
that spans multiple pages
If it spans multiple pages, doesn't this kind of imply the same instance in
the session?

Anyway thanks for this info. Any reason why a StatefulSnippet always has a
dispatch function and
a Stateless one, by default, has not?


to avoid RequestVar-s but keep state for current rendering pipeline in
 the snippet.
 2. You can indicate that you want to reuse the same instance across
 multiple pages using link or redirectTo functions from the
 StatefulSnippet

 So depending what you want to doyou can use the statefull or stateless
 nature of snippets. For stateless snippets you can just declare the
 class and the method and just use it. Such as:

 class Foo {

  def bar(xml: NodeSeq) :NodeSeq = ...
 }

 .. and in your markup

 lift:Foo.bar/

 you can also say

 class Foo  extends DispatchSniuppet {

   def dispatch = ...
 }

 which is also a stateless snippet.

 Br's,
 Marius

 On Apr 11, 7:21 am, Oliver Lambert olambo...@gmail.com wrote:
  I have a stateful snippet that doesn't always appear to work with the
 back
  button.
  Sometimes, when the back button is used, a new stateful snippet instance
  appears to be created. Has this happened to anyone else?
 
  Anyway, I've converted what I had to use a SessionVar to store the state.
  Should I replace the stateful snippet with a stateless one - does a
 stateful
  snippet that isn't storing any state have any extra overhead over a
  stateless one?
 
  If I do use a stateless snipet can I still have a dispatch method?
 
  cheers
  Oliver
 


--~--~-~--~~~---~--~~
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] JPA or JDO best for us on Google App Engine?

2009-04-11 Thread mal3

We are going to use the Google App Engine (GAE) for our app using GWT
with the new Google GWT Eclipse plugin support.

Our Scala and Lift skills are not up to the task of doing it in Lift
right now.
Once we have Exploring Lift and Beginning Scala books in our hot
little hands in May, we will begin to port the app over to Lift.

We need to choose between JPA and JDO. Which is the best choice
in anticipation of using Lift on GAE in a couple of months time?
 So far as I can see, Lift supports JPA but not JDO.

Mal.

--~--~-~--~~~---~--~~
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: JPA or JDO best for us on Google App Engine?

2009-04-11 Thread Oliver Lambert
On Sun, Apr 12, 2009 at 2:54 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:



 On Sat, Apr 11, 2009 at 8:36 PM, mal3 malcolm.gor...@gmail.com wrote:


 We are going to use the Google App Engine (GAE) for our app using GWT
 with the new Google GWT Eclipse plugin support.

 Our Scala and Lift skills are not up to the task of doing it in Lift
 right now.
 Once we have Exploring Lift and Beginning Scala books in our hot
 little hands in May, we will begin to port the app over to Lift.

 We need to choose between JPA and JDO. Which is the best choice
 in anticipation of using Lift on GAE in a couple of months time?
  So far as I can see, Lift supports JPA but not JDO.


 Lift supports either.  Lift is persistence agnostic.  Lift has a module,
 mapper, that has JDBC support.  Derek and Co. have built some nice
 JPA archetypes, but you can use JDO to your heart's content with Lift.


But there are no JDO examples while there are JPA and mapper ones.




 Mal.





 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://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: JPA or JDO best for us on Google App Engine?

2009-04-11 Thread David Pollak
On Sat, Apr 11, 2009 at 10:21 PM, Oliver Lambert olambo...@gmail.comwrote:



 On Sun, Apr 12, 2009 at 2:54 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Sat, Apr 11, 2009 at 8:36 PM, mal3 malcolm.gor...@gmail.com wrote:


 We are going to use the Google App Engine (GAE) for our app using GWT
 with the new Google GWT Eclipse plugin support.

 Our Scala and Lift skills are not up to the task of doing it in Lift
 right now.
 Once we have Exploring Lift and Beginning Scala books in our hot
 little hands in May, we will begin to port the app over to Lift.

 We need to choose between JPA and JDO. Which is the best choice
 in anticipation of using Lift on GAE in a couple of months time?
  So far as I can see, Lift supports JPA but not JDO.


 Lift supports either.  Lift is persistence agnostic.  Lift has a module,
 mapper, that has JDBC support.  Derek and Co. have built some nice
 JPA archetypes, but you can use JDO to your heart's content with Lift.


 But there are no JDO examples while there are JPA and mapper ones.



The issue is what Lift supports.  The HTTP request/response part of Lift
is agnostic about persistence.  I made sure that this was the case.  Use of
JPA in Scala/Lift was not well documented before Derek came along, but it's
quickly becoming the persistence mechanism of choice for Lift apps.  Perhaps
if folks start using JDO with Lift, that will garner community support and
there will be a lot of JDO code that people contribute.

So, I advocate using the persistence mechanism that one feels most
comfortable with.  I'll make sure that if folks start using JDO and they
contribute JDO examples into the community that JDO gets the same level of
support as JPA and mapper.

Thanks,

David






 Mal.





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





 



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: stateful vs stateless snippet

2009-04-11 Thread marius d.

As I said you CAN use it to span the same snippet instance for
multiple pages. Please see the two fundamental functions offered by
StatefulSnippet: link and redirect. Lift book provided correct
information.


On Apr 12, 5:44 am, Oliver Lambert olambo...@gmail.com wrote:
 On Sun, Apr 12, 2009 at 7:14 AM, marius d. marius.dan...@gmail.com wrote:

  The StatefulSnippet is not a snippet instance that is always used in
  the context of your session.

 Yikes! in that case, I wrote a whole application based on false assumption.
 It says in the lift book
 a StatefulSnippet is ideal for small, conversational state, such as a form
 that spans multiple pages
 If it spans multiple pages, doesn't this kind of imply the same instance in
 the session?

 Anyway thanks for this info. Any reason why a StatefulSnippet always has a
 dispatch function and
 a Stateless one, by default, has not?

The reason that I see ...
Stateless snippets are the most used artifacts to attach business
logic to your view. Because it is so common besides DispatchSnippet
trait, Lift loads and invoke Snippets functions using reflection.
Since discriminating at runtime between a stateless and a stateful
requires a trait (forget about annotations for now) well that trait is
StatefulSnippet.



 to avoid RequestVar-s but keep state for current rendering pipeline in

  the snippet.
  2. You can indicate that you want to reuse the same instance across
  multiple pages using link or redirectTo functions from the
  StatefulSnippet

  So depending what you want to doyou can use the statefull or stateless
  nature of snippets. For stateless snippets you can just declare the
  class and the method and just use it. Such as:

  class Foo {

   def bar(xml: NodeSeq) :NodeSeq = ...
  }

  .. and in your markup

  lift:Foo.bar/

  you can also say

  class Foo  extends DispatchSniuppet {

    def dispatch = ...
  }

  which is also a stateless snippet.

  Br's,
  Marius

  On Apr 11, 7:21 am, Oliver Lambert olambo...@gmail.com wrote:
   I have a stateful snippet that doesn't always appear to work with the
  back
   button.
   Sometimes, when the back button is used, a new stateful snippet instance
   appears to be created. Has this happened to anyone else?

   Anyway, I've converted what I had to use a SessionVar to store the state.
   Should I replace the stateful snippet with a stateless one - does a
  stateful
   snippet that isn't storing any state have any extra overhead over a
   stateless one?

   If I do use a stateless snipet can I still have a dispatch method?

   cheers
   Oliver
--~--~-~--~~~---~--~~
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: stateful vs stateless snippet

2009-04-11 Thread marius d.

Oh and if that helps from the Scaladoc:


 * If the StatefulSnippet is used to render a form, a hidden field is
added to
 * the form that causes the same instance to be used on the page that
is the
 * target of the form submission.


On Apr 12, 8:49 am, marius d. marius.dan...@gmail.com wrote:
 As I said you CAN use it to span the same snippet instance for
 multiple pages. Please see the two fundamental functions offered by
 StatefulSnippet: link and redirect. Lift book provided correct
 information.

 On Apr 12, 5:44 am, Oliver Lambert olambo...@gmail.com wrote:

  On Sun, Apr 12, 2009 at 7:14 AM, marius d. marius.dan...@gmail.com wrote:

   The StatefulSnippet is not a snippet instance that is always used in
   the context of your session.

  Yikes! in that case, I wrote a whole application based on false assumption.
  It says in the lift book
  a StatefulSnippet is ideal for small, conversational state, such as a form
  that spans multiple pages
  If it spans multiple pages, doesn't this kind of imply the same instance in
  the session?

  Anyway thanks for this info. Any reason why a StatefulSnippet always has a
  dispatch function and
  a Stateless one, by default, has not?

 The reason that I see ...
 Stateless snippets are the most used artifacts to attach business
 logic to your view. Because it is so common besides DispatchSnippet
 trait, Lift loads and invoke Snippets functions using reflection.
 Since discriminating at runtime between a stateless and a stateful
 requires a trait (forget about annotations for now) well that trait is
 StatefulSnippet.



  to avoid RequestVar-s but keep state for current rendering pipeline in

   the snippet.
   2. You can indicate that you want to reuse the same instance across
   multiple pages using link or redirectTo functions from the
   StatefulSnippet

   So depending what you want to doyou can use the statefull or stateless
   nature of snippets. For stateless snippets you can just declare the
   class and the method and just use it. Such as:

   class Foo {

    def bar(xml: NodeSeq) :NodeSeq = ...
   }

   .. and in your markup

   lift:Foo.bar/

   you can also say

   class Foo  extends DispatchSniuppet {

     def dispatch = ...
   }

   which is also a stateless snippet.

   Br's,
   Marius

   On Apr 11, 7:21 am, Oliver Lambert olambo...@gmail.com wrote:
I have a stateful snippet that doesn't always appear to work with the
   back
button.
Sometimes, when the back button is used, a new stateful snippet instance
appears to be created. Has this happened to anyone else?

Anyway, I've converted what I had to use a SessionVar to store the 
state.
Should I replace the stateful snippet with a stateless one - does a
   stateful
snippet that isn't storing any state have any extra overhead over a
stateless one?

If I do use a stateless snipet can I still have a dispatch method?

cheers
Oliver
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---