[Lift] Re: how / where to set the runmode of a lift application?
Thanks Xavi I believe you can also modify web.xml in some way, but I'm not really sure. that would be useful as I don't have the ability to set properties on the production environment. I wonder if anyone else can confirm? --~--~-~--~~~---~--~~ 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] using jquery 1.3.2 and 'tabs'
I'd like to use the latest jquery, 1.3.2. I'm new to both jquery and
lift but I like what I see!
script type=text/javascript src=../js/jquery-1.3.2.js/
script
script type=text/javascript src=../js/ui/ui.core.js/script
script type=text/javascript src=../js/ui/ui.tabs.js/script
script id=json src=/classpath/json.js type=text/javascript/
script type=text/javascript
$(function() {
$(#tabs).tabs();
});
/script
/head
body
lift:surround with=default at=content
I get this error:
$(#tabs).tabs is not a function
http://localhost:8080/hello
Line 33
Is it possible to mix separately downloaded jquery? If I save the
'source' of the html after lift has processed, from the browser,
jquery tabs are working. But from the dynamic jetty instance, the
tabs do not work and I get that error.
Thanks for any help you can provide.
--~--~-~--~~~---~--~~
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-json
Sorry, here's the full code I'm using:
case class MyName(first:String, last:String)
case class MyUser(id:String, name:MyName, url:String) {
val wtf = wtf
}
implicit val formats = net.liftweb.json.DefaultFormats
val json =
(id - me.id) ~
(name -
(first - me.name.first) ~
(last - me.name.last)
) ~
(url - me.url)
val output = JsonDSL.pretty(render(json))
val jsonCopy = parse(output)
val user = jsonCopy.extract[MyUser]
println(user = +user)
On Sun, Sep 13, 2009 at 12:07 AM, linxbetter linxbet...@gmail.com wrote:
Hello, I saw a post about lift-json on the scala-user list so I
decided to check it out. I was particularly interested in the ability
to call something along the lines of json.extract[MyClass]. I set up
a little test case for this though, and apparently having a val of any
sort in my case class causes the below exception. Any thoughts?
My classes looked like this:
case class MyName(first:String, last:String)
case class MyUser(id:String, name:MyName, url:String) {
val wtf = wtf
}
And the output of my test
[info] lift-json should
[info] x do pain-free json conversion on nested objects
net.liftweb.json.MappingException: Expected JField but got JNothing,
json='JField(name,JObject(List(JField(first,JString(Lincoln)), JField
(last,JString(Hochberg)', path='wtf'
at net.liftweb.json.Extraction$.net$liftweb$json$Extraction$
$fail(Extraction.scala:151)
at net.liftweb.json.Extraction$.fieldValue$1(Extraction.scala:
106)
at net.liftweb.json.Extraction$.build$1(Extraction.scala:78)
at net.liftweb.json.Extraction$$anonfun$1.apply
(Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply
(Extraction.scala:84)
at scala.List.flatMap(List.scala:1132)
at net.liftweb.json.Extraction$.build$1(Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply
(Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply
(Extraction.scala:84)
at scala.List.flatMap(List.scala:1132)
at net.liftweb.json.Extraction$.build$1(Extraction.scala:84)
at net.liftweb.json.Extraction$.extract0(Extraction.scala:109)
at net.liftweb.json.Extraction$.extract(Extraction.scala:60)
at net.liftweb.json.JsonAST$JValue.extract(Json.scala:109)
at com.hotpotato.core.SerializationSpec$$anonfun$1$$anonfun
$apply$1.apply(SerializationSpec.scala:87)
at com.hotpotato.core.SerializationSpec$$anonfun$1$$anonfun
$apply$1.apply(SerializationSpec.scala:69)
at org.specs.specification.ExampleExecution$$anonfun$3$$anonfun
$apply$1.apply(Example.scala:207)
at org.specs.specification.Example.execute(Example.scala:121)
at org.specs.specification.ExampleLifeCycle$class.executeTest
(ExampleLifeCycle.scala:20)
at org.specs.Specification.executeTest(Specification.scala:28)
at org.specs.specification.Sus.executeTest(Sus.scala:147)
at org.specs.specification.ExampleExecution$$anonfun$3.apply
(Example.scala:207)
at org.specs.specification.ExampleExecution$$anonfun$3.apply
(Example.scala:194)
at org.specs.specification.ExampleExecution$$anonfun$2.apply
(Example.scala:185)
at org.specs.specification.ExampleExecution.execute
(Example.scala:227)
at org.specs.specification.Example.execute(Example.scala:117)
at org.specs.specification.Example.errors(Example.scala:143)
at org.specs.specification.Sus$$anonfun$successes$1.apply
(Sus.scala:122)
at org.specs.specification.Sus$$anonfun$successes$1.apply
(Sus.scala:122)
at scala.List.filter(List.scala:859)
at org.specs.specification.Sus.successes(Sus.scala:122)
at org.specs.Specification$$anonfun$successes$1.apply
(Specification.scala:84)
at org.specs.Specification$$anonfun$successes$1.apply
(Specification.scala:84)
at scala.List.flatMap(List.scala:1132)
at org.specs.Specification.successes(Specification.scala:84)
at sbt.impl.SpecsRunner.sbt$impl$SpecsRunner$
$reportSpecification(TestFrameworkImpl.scala:140)
at sbt.impl.SpecsRunner.runTest(TestFrameworkImpl.scala:123)
at sbt.BasicTestRunner.run(TestFramework.scala:38)
at sbt.TestFramework$$anonfun$7$$anonfun$apply$8.runTest$1
(TestFramework.scala:136)
at sbt.TestFramework$$anonfun$7$$anonfun$apply$8$$anonfun$apply
$9.apply(TestFramework.scala:147)
at sbt.TestFramework$$anonfun$7$$anonfun$apply$8$$anonfun$apply
$9.apply(TestFramework.scala:147)
at sbt.NamedTestTask.run(TestFramework.scala:57)
at sbt.ScalaProject$$anonfun$sbt$ScalaProject$$toTask$1.apply
(ScalaProject.scala:167)
at sbt.ScalaProject$$anonfun$sbt$ScalaProject$$toTask$1.apply
(ScalaProject.scala:167)
at sbt.TaskManager$Task.invoke(TaskManager.scala:62)
at sbt.impl.RunTask.runTask(RunTask.scala:78)
at sbt.impl.RunTask.sbt$impl$RunTask$$runIfNotRoot
(RunTask.scala:63)
[Lift] lift-json
Hello, I saw a post about lift-json on the scala-user list so I
decided to check it out. I was particularly interested in the ability
to call something along the lines of json.extract[MyClass]. I set up
a little test case for this though, and apparently having a val of any
sort in my case class causes the below exception. Any thoughts?
My classes looked like this:
case class MyName(first:String, last:String)
case class MyUser(id:String, name:MyName, url:String) {
val wtf = wtf
}
And the output of my test
[info] lift-json should
[info] x do pain-free json conversion on nested objects
net.liftweb.json.MappingException: Expected JField but got JNothing,
json='JField(name,JObject(List(JField(first,JString(Lincoln)), JField
(last,JString(Hochberg)', path='wtf'
at net.liftweb.json.Extraction$.net$liftweb$json$Extraction$
$fail(Extraction.scala:151)
at net.liftweb.json.Extraction$.fieldValue$1(Extraction.scala:
106)
at net.liftweb.json.Extraction$.build$1(Extraction.scala:78)
at net.liftweb.json.Extraction$$anonfun$1.apply
(Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply
(Extraction.scala:84)
at scala.List.flatMap(List.scala:1132)
at net.liftweb.json.Extraction$.build$1(Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply
(Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply
(Extraction.scala:84)
at scala.List.flatMap(List.scala:1132)
at net.liftweb.json.Extraction$.build$1(Extraction.scala:84)
at net.liftweb.json.Extraction$.extract0(Extraction.scala:109)
at net.liftweb.json.Extraction$.extract(Extraction.scala:60)
at net.liftweb.json.JsonAST$JValue.extract(Json.scala:109)
at com.hotpotato.core.SerializationSpec$$anonfun$1$$anonfun
$apply$1.apply(SerializationSpec.scala:87)
at com.hotpotato.core.SerializationSpec$$anonfun$1$$anonfun
$apply$1.apply(SerializationSpec.scala:69)
at org.specs.specification.ExampleExecution$$anonfun$3$$anonfun
$apply$1.apply(Example.scala:207)
at org.specs.specification.Example.execute(Example.scala:121)
at org.specs.specification.ExampleLifeCycle$class.executeTest
(ExampleLifeCycle.scala:20)
at org.specs.Specification.executeTest(Specification.scala:28)
at org.specs.specification.Sus.executeTest(Sus.scala:147)
at org.specs.specification.ExampleExecution$$anonfun$3.apply
(Example.scala:207)
at org.specs.specification.ExampleExecution$$anonfun$3.apply
(Example.scala:194)
at org.specs.specification.ExampleExecution$$anonfun$2.apply
(Example.scala:185)
at org.specs.specification.ExampleExecution.execute
(Example.scala:227)
at org.specs.specification.Example.execute(Example.scala:117)
at org.specs.specification.Example.errors(Example.scala:143)
at org.specs.specification.Sus$$anonfun$successes$1.apply
(Sus.scala:122)
at org.specs.specification.Sus$$anonfun$successes$1.apply
(Sus.scala:122)
at scala.List.filter(List.scala:859)
at org.specs.specification.Sus.successes(Sus.scala:122)
at org.specs.Specification$$anonfun$successes$1.apply
(Specification.scala:84)
at org.specs.Specification$$anonfun$successes$1.apply
(Specification.scala:84)
at scala.List.flatMap(List.scala:1132)
at org.specs.Specification.successes(Specification.scala:84)
at sbt.impl.SpecsRunner.sbt$impl$SpecsRunner$
$reportSpecification(TestFrameworkImpl.scala:140)
at sbt.impl.SpecsRunner.runTest(TestFrameworkImpl.scala:123)
at sbt.BasicTestRunner.run(TestFramework.scala:38)
at sbt.TestFramework$$anonfun$7$$anonfun$apply$8.runTest$1
(TestFramework.scala:136)
at sbt.TestFramework$$anonfun$7$$anonfun$apply$8$$anonfun$apply
$9.apply(TestFramework.scala:147)
at sbt.TestFramework$$anonfun$7$$anonfun$apply$8$$anonfun$apply
$9.apply(TestFramework.scala:147)
at sbt.NamedTestTask.run(TestFramework.scala:57)
at sbt.ScalaProject$$anonfun$sbt$ScalaProject$$toTask$1.apply
(ScalaProject.scala:167)
at sbt.ScalaProject$$anonfun$sbt$ScalaProject$$toTask$1.apply
(ScalaProject.scala:167)
at sbt.TaskManager$Task.invoke(TaskManager.scala:62)
at sbt.impl.RunTask.runTask(RunTask.scala:78)
at sbt.impl.RunTask.sbt$impl$RunTask$$runIfNotRoot
(RunTask.scala:63)
at sbt.impl.RunTask$$anonfun$runTasksExceptRoot$3.apply
(RunTask.scala:49)
at sbt.impl.RunTask$$anonfun$runTasksExceptRoot$3.apply
(RunTask.scala:49)
at sbt.Distributor$Run$Worker$$anonfun$2.apply
(ParallelRunner.scala:130)
at sbt.Distributor$Run$Worker$$anonfun$2.apply
(ParallelRunner.scala:130)
at sbt.Control$.trapUnit(Control.scala:19)
at sbt.Distributor$Run$Worker.run(ParallelRunner.scala:130)
[error] net.liftweb.json.MappingException: Expected JField but got
JNothing,
[Lift] Re: how / where to set the runmode of a lift application?
If you are modifying web.xml, doing it via env-entry/ and having it available via JNDI (java:comp/env) [1] seems closest. However, I am not sure that would be available via System.getProperty (). Alternately, try jetty.xml (or jetty-env.xml, if possible) [2][3] to do something like: Call class=java.lang.System name=setProperty Argrun.mode/Arg Argproduction/Arg /Call [1]: http://docs.codehaus.org/display/JETTY/JNDI#JNDI-enventry [2]: http://docs.codehaus.org/display/JETTY/Syntax+Reference [3]: http://docs.codehaus.org/display/JETTY/jetty-env.xml On Sep 13, 1:47 pm, george geo...@mattandgeorge.com wrote: Thanks Xavi I believe you can also modify web.xml in some way, but I'm not really sure. that would be useful as I don't have the ability to set properties on the production environment. I wonder if anyone else can confirm? --~--~-~--~~~---~--~~ 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] how to send an attachment using Mailer?
hello all
I need to send a pdf attachment with my xhtml mail body.
At first I thought I might be able to treat it as an inline image
(byte array). But this doesn't seem to work (the pdf file has 0 bytes
when received).
Then I thought I could make my own MailBodyType and include it that
way, but it seems the design of the Mailer singleton doesn't allow me
to do this.
I need to be able to do something like this:
val attachment = new MimeBodyPart
attachment.setFileName(fileName)
attachment.setContentID(fileName)
attachment.setDisposition(attachment)
attachment.setDataHandler(new _root_.javax.activation.DataHandler(new
_root_.javax.activation.DataSource {
def getContentType = application/pdf
def getInputStream = new _root_.java.io.ByteArrayInputStream
(pdf.toByteArray)
def getName = fileName
def getOutputStream = throw new _root_.java.io.IOException(Unable to
write to item)
}))
The ability to somehow add arbitrary attachments to an email would be
a very useful feature I think.
Is there a way to do it that I have missed?
--~--~-~--~~~---~--~~
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: how to send an attachment using Mailer?
update: ok, so it turns out that you can send pdfs as inline attachments using XHTMLPlusImages. (the byte array being empty was my fault). however, it would still be good to be able to add arbitrary attachments. a pdf isn't really an image. --~--~-~--~~~---~--~~ 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-json
Got it. Thanks for the info. I was afraid I was doing something wrong.
Thanks,
Lincoln
On Sun, Sep 13, 2009 at 9:48 AM, Joni Freeman freeman.j...@gmail.comwrote:
Hi,
Your example should work if you take the val away from your case
class:
case class MyName(first:String, last:String)
case class MyUser(id:String, name:MyName, url:String)
The reflection code currently fails to find the primary constructor of
case class if there's extra fields. This will hopefully be fixed some
day when the reflection story of Scala gets better (using Java
reflection is very awkward).
Cheers Joni
On Sep 13, 7:55 am, Lincoln linxbet...@gmail.com wrote:
Sorry, here's the full code I'm using:
case class MyName(first:String, last:String)
case class MyUser(id:String, name:MyName, url:String) {
val wtf = wtf
}
implicit val formats = net.liftweb.json.DefaultFormats
val json =
(id - me.id) ~
(name -
(first - me.name.first) ~
(last - me.name.last)
) ~
(url - me.url)
val output = JsonDSL.pretty(render(json))
val jsonCopy = parse(output)
val user = jsonCopy.extract[MyUser]
println(user = +user)
On Sun, Sep 13, 2009 at 12:07 AM, linxbetter linxbet...@gmail.com
wrote:
Hello, I saw a post about lift-json on the scala-user list so I
decided to check it out. I was particularly interested in the ability
to call something along the lines of json.extract[MyClass]. I set up
a little test case for this though, and apparently having a val of any
sort in my case class causes the below exception. Any thoughts?
My classes looked like this:
case class MyName(first:String, last:String)
case class MyUser(id:String, name:MyName, url:String) {
val wtf = wtf
}
And the output of my test
[info] lift-json should
[info] x do pain-free json conversion on nested objects
net.liftweb.json.MappingException: Expected JField but got JNothing,
json='JField(name,JObject(List(JField(first,JString(Lincoln)), JField
(last,JString(Hochberg)', path='wtf'
at net.liftweb.json.Extraction$.net$liftweb$json$Extraction$
$fail(Extraction.scala:151)
at net.liftweb.json.Extraction$.fieldValue$1(Extraction.scala:
106)
at net.liftweb.json.Extraction$.build$1(Extraction.scala:78)
at net.liftweb.json.Extraction$$anonfun$1.apply
(Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply
(Extraction.scala:84)
at scala.List.flatMap(List.scala:1132)
at net.liftweb.json.Extraction$.build$1(Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply
(Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply
(Extraction.scala:84)
at scala.List.flatMap(List.scala:1132)
at net.liftweb.json.Extraction$.build$1(Extraction.scala:84)
at net.liftweb.json.Extraction$.extract0(Extraction.scala:109)
at net.liftweb.json.Extraction$.extract(Extraction.scala:60)
at net.liftweb.json.JsonAST$JValue.extract(Json.scala:109)
at com.hotpotato.core.SerializationSpec$$anonfun$1$$anonfun
$apply$1.apply(SerializationSpec.scala:87)
at com.hotpotato.core.SerializationSpec$$anonfun$1$$anonfun
$apply$1.apply(SerializationSpec.scala:69)
at org.specs.specification.ExampleExecution$$anonfun$3$$anonfun
$apply$1.apply(Example.scala:207)
at org.specs.specification.Example.execute(Example.scala:121)
at org.specs.specification.ExampleLifeCycle$class.executeTest
(ExampleLifeCycle.scala:20)
at org.specs.Specification.executeTest(Specification.scala:28)
at org.specs.specification.Sus.executeTest(Sus.scala:147)
at org.specs.specification.ExampleExecution$$anonfun$3.apply
(Example.scala:207)
at org.specs.specification.ExampleExecution$$anonfun$3.apply
(Example.scala:194)
at org.specs.specification.ExampleExecution$$anonfun$2.apply
(Example.scala:185)
at org.specs.specification.ExampleExecution.execute
(Example.scala:227)
at org.specs.specification.Example.execute(Example.scala:117)
at org.specs.specification.Example.errors(Example.scala:143)
at org.specs.specification.Sus$$anonfun$successes$1.apply
(Sus.scala:122)
at org.specs.specification.Sus$$anonfun$successes$1.apply
(Sus.scala:122)
at scala.List.filter(List.scala:859)
at org.specs.specification.Sus.successes(Sus.scala:122)
at org.specs.Specification$$anonfun$successes$1.apply
(Specification.scala:84)
at org.specs.Specification$$anonfun$successes$1.apply
(Specification.scala:84)
at scala.List.flatMap(List.scala:1132)
at org.specs.Specification.successes(Specification.scala:84)
at sbt.impl.SpecsRunner.sbt$impl$SpecsRunner$
$reportSpecification(TestFrameworkImpl.scala:140)
at
[Lift] Re: Lift deal breakers
I also think that javascript should go just before the boby's closing
tag. The main reason: Yahoo's YSlow and Google's Page speed both
telling you that is better to have as less scripts as possible and all
of them placed at the end of the page. The optimal would be one
javascript at the end of the page no matter how big it is as it would
be cached by any modern browser and it will be used from the local
cache on other requests from the same domain.
Of course optimal is not always what you can get. Assuming that you
have many javascript files it is also better to have them at the
bottom of the page. You will see a major performance boost because
browsers pause the rendering of the page in order to download
javascript. That is because javascript code could contain a
document.write witch means that it will change the dom of the page and
this is something that the browser will not be able to know in advance
in order to continue the parsing of the page. Moving javascript at the
bottom of the page will not decrease the page loading time BUT will
give the user something to see (the whole page) making him thing that
the page loads faster. Of course the browser will still have to get
the javascript and eval it.
As for unobtrusive, jquery (and the most js frameworks) provides a
solution binding an event on an html element after the page has been
loaded. So instead of having somthing like:
button onclick=liftAjax.lift_ajaxHandler
(quot;F1029758482780OTA=truequot;,
null, null, null); return false;Press me/button
you could have something like:
button id=liftajax_{some_generated_id}Press me/button
and at the end of the page add the javascript:
text type=text/javascript
$(function() {
$(#liftajax_{some_generated_id}).click(function()
{the_lift_ajaxHandler_call_here()})
})
/script
If the ajax handle call is basically the same for most of the elements
you could instead of adding an id, add a class to the the button for
example:
button class=liftajaxPress me/button
and then at the end of the page add:
text type=text/javascript
$(function() {
$(.liftajax).click(function() {the_lift_ajaxHandler_call_here()})
})
/script
I personally use jQuery but the above can be done without the help of
any javascript framework. And to make things much more better you
could have all the handler scripts in a separete dynamicaly created
file and the at the end of the html have something like:
script type=text/javscript src=/path/to/the/dynamicaly/created/js/
with/a/random/id/to/prevent/caching/script
One reason for keeping me away from using lift for a project is this
mess with javascript. I mean, I first want plain html and nothing
else. If I get the html to work for me the I just add the javascript I
want or let the framework add it, but that should be done in an
elegant way in order to be able to switch it off or on or completely
replace it with my own. I don't want any framework to add by default
the javascript for me because it makes things harder to understand and
this is something bad for someone new to it.
I would be glad to help in this matter in any way possible.
Sorry for my English,
it's not my mother language!
Yoryos
On Sep 13, 6:35 am, marius d. marius.dan...@gmail.com wrote:
Technically it could (as I implied above) but this can be lucrative
and IMHO the benefits are simply not that big. I'm not saying that
things are nailed down but I'd love to see a list of practical
benefits for Lift to not add event handlers such as on click to the
elements but rather programatically using synthetic (lift generated)
JS functions that would add events (i.e. JQuery, YUI ways).
Br's,
Marius
On Sep 12, 9:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
Maybe adding javascript event handlers could be delegated to something that
depends on which library is being used?
-
Kevin Wrightkev.lee.wri...@googlemail.com wrote:
Moving the script import shouldn't be too difficult, we have the lift:tail
element and tail merge (which acts exactly the same as head merge) for just
this sort of problem.
On Sat, Sep 12, 2009 at 8:07 PM, Dustin Whitney
dustin.whit...@gmail.comwrote:
One nice thing about jquery's events, if done wisely, is they are applied
after the DOM is loaded. With an onclick a button can be clicked and some
ajax call is fired that returns and tries to modify a part of the DOM that
hasn't been loaded. This is especially true if you have lots of
javascript
includes at the top of the page. I have waded my way through many wonky
javascript bugs like this. They don't happen in your local environment
because they load so quickly, but when pushed to production, problems
ensue. Maybe there is a hook in the lift ajax js that waits to fire the
call until after the DOM is loaded?
-D
On Sat, Sep 12, 2009 at 2:48 PM, Charles F. Munat c...@munat.com wrote:
I, too, would like to be able to move the liftAjax script call to
[Lift] Best way to write a wizard
All, I write to you (unfortunately still) as a lift n00b. I'm trying to modify a form such that it looks more wizard like. i.e. I want it to specifically state You've completed part 1, you're on step 2 of 5, etc. How should I accomplish this in view-first rendering? Normal MVC, I'd make one controll that redirects you to the appropriate wizard screen depending on what steps have already been accomplished (i.e. the controller figures out which step you're on and sends you to the appropraite view. In Lift, I'm thinking I have a few options: 1) Have my stateful snippet actually return the various pages in code. I'm not happy with this, as my view would reside in the controller, but I could git'r'done this way. 2) Attempt to learn the lift-wizard library (is this stable/released?) 3) Spend more time trying to be inventive. Anyone have any thoughts? - Josh --~--~-~--~~~---~--~~ 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: using jquery 1.3.2 and 'tabs'
David,
1. Lift includes jquery-1.3.2, just do:
script id=jquery src=/classpath/jquery.js type=text/
javascript/script and your done.
2. For the other stuff:
a. Put the files in src/main/resources/toserve/ui (e.g., src/main/
resources/toserve/ui/ui.tabs.js)
b. Add them to ResourceServer.allowedPaths by adding this to Boot:
ResourceServer.allow {
case ui :: _ = true
}
c. Refer them as script id=jquery src=/classpath/ui/ui.tabs.js
type=text/javascript/script
Hope this helps.
Cheers, Indrajit
On Sep 13, 9:43 am, David david.b...@gmail.com wrote:
I'd like to use the latest jquery, 1.3.2. I'm new to both jquery and
lift but I like what I see!
script type=text/javascript src=../js/jquery-1.3.2.js/
script
script type=text/javascript src=../js/ui/ui.core.js/script
script type=text/javascript src=../js/ui/ui.tabs.js/script
script id=json src=/classpath/json.js type=text/javascript/
script type=text/javascript
$(function() {
$(#tabs).tabs();
});
/script
/head
body
lift:surround with=default at=content
I get this error:
$(#tabs).tabs is not a functionhttp://localhost:8080/hello
Line 33
Is it possible to mix separately downloaded jquery? If I save the
'source' of the html after lift has processed, from the browser,
jquery tabs are working. But from the dynamic jetty instance, the
tabs do not work and I get that error.
Thanks for any help you can provide.
--~--~-~--~~~---~--~~
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 deal breakers
On Sep 13, 11:33 am, valotas valo...@gmail.com wrote:
I also think that javascript should go just before the boby's closing
tag. The main reason: Yahoo's YSlow and Google's Page speed both
telling you that is better to have as less scripts as possible and all
of them placed at the end of the page. The optimal would be one
javascript at the end of the page no matter how big it is as it would
be cached by any modern browser and it will be used from the local
cache on other requests from the same domain.
Of course optimal is not always what you can get. Assuming that you
have many javascript files it is also better to have them at the
bottom of the page. You will see a major performance boost because
browsers pause the rendering of the page in order to download
javascript. That is because javascript code could contain a
document.write witch means that it will change the dom of the page and
this is something that the browser will not be able to know in advance
in order to continue the parsing of the page. Moving javascript at the
bottom of the page will not decrease the page loading time BUT will
give the user something to see (the whole page) making him thing that
the page loads faster. Of course the browser will still have to get
the javascript and eval it.
As for unobtrusive, jquery (and the most js frameworks) provides a
solution binding an event on an html element after the page has been
loaded. So instead of having somthing like:
button onclick=liftAjax.lift_ajaxHandler
(quot;F1029758482780OTA=truequot;,
null, null, null); return false;Press me/button
you could have something like:
button id=liftajax_{some_generated_id}Press me/button
and at the end of the page add the javascript:
text type=text/javascript
$(function() {
$(#liftajax_{some_generated_id}).click(function()
{the_lift_ajaxHandler_call_here()})})
/script
That looks a little cleaner but we'll have to look more into it if
we'd want to go on this path. Perhaps accumulate those function into
synthetic js file .. we'll see
If the ajax handle call is basically the same for most of the elements
you could instead of adding an id, add a class to the the button for
example:
button class=liftajaxPress me/button
and then at the end of the page add:
text type=text/javascript
$(function() {
$(.liftajax).click(function() {the_lift_ajaxHandler_call_here()})})
Two reason why I don't prefer this:
1. Lots of selectors could slow things down
2. Other JS frameworks may not have nice selectors as JQuery
/script
I personally use jQuery but the above can be done without the help of
any javascript framework. And to make things much more better you
could have all the handler scripts in a separete dynamicaly created
file and the at the end of the html have something like:
script type=text/javscript src=/path/to/the/dynamicaly/created/js/
with/a/random/id/to/prevent/caching/script
One reason for keeping me away from using lift for a project is this
mess with javascript. I mean, I first want plain html and nothing
else. If I get the html to work for me the I just add the javascript I
want or let the framework add it, but that should be done in an
elegant way in order to be able to switch it off or on or completely
replace it with my own. I don't want any framework to add by default
the javascript for me because it makes things harder to understand and
this is something bad for someone new to it.
I would be glad to help in this matter in any way possible.
Sorry for my English,
it's not my mother language!
I think this is a great post !
Yoryos
On Sep 13, 6:35 am, marius d. marius.dan...@gmail.com wrote:
Technically it could (as I implied above) but this can be lucrative
and IMHO the benefits are simply not that big. I'm not saying that
things are nailed down but I'd love to see a list of practical
benefits for Lift to not add event handlers such as on click to the
elements but rather programatically using synthetic (lift generated)
JS functions that would add events (i.e. JQuery, YUI ways).
Br's,
Marius
On Sep 12, 9:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
Maybe adding javascript event handlers could be delegated to something
that depends on which library is being used?
-
Kevin Wrightkev.lee.wri...@googlemail.com wrote:
Moving the script import shouldn't be too difficult, we have the
lift:tail
element and tail merge (which acts exactly the same as head merge) for
just
this sort of problem.
On Sat, Sep 12, 2009 at 8:07 PM, Dustin Whitney
dustin.whit...@gmail.comwrote:
One nice thing about jquery's events, if done wisely, is they are
applied
after the DOM is loaded. With an onclick a button can be clicked and
some
ajax call is fired that returns and tries to modify a part of the DOM
that
hasn't been loaded. This is especially true if you have lots
[Lift] Getting Maven Offline Mode Working
Hi all, I'm having problems running mvn -o jetty:run with my version of Lift (1.1-SNAPSHOT) because Maven thinks that net.liftweb:lift-core:jar:1.1- SNAPSHOT is missing. How do I fix that? My pom.xml is here: http://gist.github.com/186293 I've got an international plane flight in 24 hours, so I'd love to have offline mode working for then. Thanks for the help! Peter --~--~-~--~~~---~--~~ 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: Getting Maven Offline Mode Working
Try updating to the latest maven, older versions have known issues with offline behaviour for snapshots. On Sun, Sep 13, 2009 at 8:55 PM, Peter Robinett pe...@bubblefoundry.comwrote: Hi all, I'm having problems running mvn -o jetty:run with my version of Lift (1.1-SNAPSHOT) because Maven thinks that net.liftweb:lift-core:jar:1.1- SNAPSHOT is missing. How do I fix that? My pom.xml is here: http://gist.github.com/186293 I've got an international plane flight in 24 hours, so I'd love to have offline mode working for then. Thanks for the help! Peter --~--~-~--~~~---~--~~ 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 deal breakers
A synthetic file sounds good to me and would probably be preferable. Cheers, Tim On 13 Sep 2009, at 20:31, marius d. wrote: That looks a little cleaner but we'll have to look more into it if we'd want to go on this path. Perhaps accumulate those function into synthetic js file .. we'll see --~--~-~--~~~---~--~~ 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] Why isn't this a trait in lift-json?
Just had a browse over the latest commit and found the following in
path.java:
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface path {
public String value();
}
Any reason were not using a trait etc to complete the same
functionality?
Cheers, Tim
--~--~-~--~~~---~--~~
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: Why isn't this a trait in lift-json?
Hi,
That annotation is used to configure the json path when extracting
values. By default the extraction code assumes that case class
parameter names match with json field names. For instance these match:
case class Foo(bar: String, baz: Int)
{ bar: qwerty, baz: 10 }
But sometimes json field names can contain characters which are not
allowed in Scala identifiers. For example:
{ foo-bar: qwerty, baz: 10 }
Now, to able to extract this we have to somehow tell the extractor the
exact path explicitly. Currently @path annotation is used for that:
case class Foo(@path(foo-bar) bar: String, baz: Int)
I don't see how a trait can accomplish this, maybe I'm missing
something?
The reason why it is in Java is that Scala annotations are not
accessible at runtime.
Cheers Joni
On Sep 13, 11:03 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Just had a browse over the latest commit and found the following in
path.java:
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface path {
public String value();
}
Any reason were not using a trait etc to complete the same
functionality?
Cheers, Tim
--~--~-~--~~~---~--~~
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: Best way to write a wizard
It just seems to me that you can already do what you detailed using chooseTemplate? My concern about having multiple ways to do a single task IMHO makes it more confusing for n00bs... Much better if there is a clear problem:solution relationship :-) we already have chooseTemplate right? About wizard, you are right that is what dpp said - however, it's been my experience of dave that if the comunity is discussing soemthing and it keeps comming up (like the wizard) then he generally rolls his sleeves up and gets the job done somehow! Cheers, Tim Sent from my iPhone On 13 Sep 2009, at 21:35, Naftoli Gugenheim naftoli...@gmail.com wrote: What do you mean mixed messages? Do you object to committing bindSwitch--after all it's much more general and basic than wizards--or that it's what Josh should use? Also, I read that DPP said it would take him 2-3 days once he found 2-3 days free to apply himself to lift-wizard. Did I miss a message where he said that he found the time already? - Timothy Perretttimo...@getintheloop.eu wrote: Naftoli, Whilst I commend your idea of bindSwitch, im really not sure that is the right way forward and would only confuse people (we dont want mixed messages). DPP will in two days or less have the wizard in a workable state so i would recommend doing just hanging out until that is completed... by the sounds of it that will provide a much better solution for Josh. Cheers, Tim On 13 Sep 2009, at 20:33, Naftoli Gugenheim wrote: I will try, G-d willing, to commit code today that allows you to bindSwitch -- that is, you give it a list of nodes, one of which is bound; and the others are replaced with NodeSeq.Empty. I used it in a view that had several parts that depend on the state. E.g., if you have not selected a client you see a search box with a button that either chooses a client if there's 1 result, or taked you to a search page. Once a client is selected, you see the clients info with a hyperlink to edit his info, and a button to unselect the client. So you could also use it for wizards. But there's also lift-wizard, which is a work in progress and may be more than what you need; I haven't looked at it myself. But my understanding is that there are usable pieces, it just needs to be polished and tied together. - Josh Suerethjoshua.suer...@gmail.com wrote: All, I write to you (unfortunately still) as a lift n00b. I'm trying to modify a form such that it looks more wizard like. i.e. I want it to specifically state You've completed part 1, you're on step 2 of 5, etc. How should I accomplish this in view-first rendering? Normal MVC, I'd make one controll that redirects you to the appropriate wizard screen depending on what steps have already been accomplished (i.e. the controller figures out which step you're on and sends you to the appropraite view. In Lift, I'm thinking I have a few options: 1) Have my stateful snippet actually return the various pages in code. I'm not happy with this, as my view would reside in the controller, but I could git'r'done this way. 2) Attempt to learn the lift-wizard library (is this stable/ released?) 3) Spend more time trying to be inventive. Anyone have any thoughts? - Josh --~--~-~--~~~---~--~~ 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 deal breakers
I think so too. Does anyone have an opinion against this? I'll probably have some time this week or next weekend to work on it. Br's, Marius On Sep 13, 2:59 pm, Timothy Perrett timo...@getintheloop.eu wrote: A synthetic file sounds good to me and would probably be preferable. Cheers, Tim On 13 Sep 2009, at 20:31, marius d. wrote: That looks a little cleaner but we'll have to look more into it if we'd want to go on this path. Perhaps accumulate those function into synthetic js file .. we'll see --~--~-~--~~~---~--~~ 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: Best way to write a wizard
Well, you could do it with bind too, or just write your own xml recursion. :) With chooseTemplate, you (1) need to have a specific location in the xml that you're binding the results of chooseTemplate to, i.e., the BindParam that holds the chosen part of the view. (2) The part of the view selected with chooseTemplate is contextless -- there's no particular place in the view it belongs. (3) Whichever template is not being used has to be replaced with NodeSeq.Empty. Now these issues are solved if you put the alternatives inside the node that's being used in bind, but what if you accidentally include another xml element with the same prefix/label somewhere else? I'm not saying there isn't a place for chooseTemplate, but for this usage, to me it seems much cleaner using an inline switch. For a two-way switch you need 2 nodes, not 3, and they go in the right place in the view. If I'm not being clear I'll try to post illustrational examples later. As to confusing newbies looking through the code, as per David's suggestion it will go into a separate object, which I called BindPlus (any other suggestion for a name?), which also will have an implicit allowing you to call the bind methods on a NodeSeq, allowing one to chain bind calls (useful for multiple prefixes nested binding like binding a name inside a link). The idea is that all sorts of binding extras can go there. I obviously have no problem with Josh using lift-wizard if it's good enough now or in two days, as was pretty clear from my original message! But his main concern seemed to be switching the view, so I mentioned this option as well. - Timothy Perretttimo...@getintheloop.eu wrote: It just seems to me that you can already do what you detailed using chooseTemplate? My concern about having multiple ways to do a single task IMHO makes it more confusing for n00bs... Much better if there is a clear problem:solution relationship :-) we already have chooseTemplate right? About wizard, you are right that is what dpp said - however, it's been my experience of dave that if the comunity is discussing soemthing and it keeps comming up (like the wizard) then he generally rolls his sleeves up and gets the job done somehow! Cheers, Tim Sent from my iPhone On 13 Sep 2009, at 21:35, Naftoli Gugenheim naftoli...@gmail.com wrote: What do you mean mixed messages? Do you object to committing bindSwitch--after all it's much more general and basic than wizards--or that it's what Josh should use? Also, I read that DPP said it would take him 2-3 days once he found 2-3 days free to apply himself to lift-wizard. Did I miss a message where he said that he found the time already? - Timothy Perretttimo...@getintheloop.eu wrote: Naftoli, Whilst I commend your idea of bindSwitch, im really not sure that is the right way forward and would only confuse people (we dont want mixed messages). DPP will in two days or less have the wizard in a workable state so i would recommend doing just hanging out until that is completed... by the sounds of it that will provide a much better solution for Josh. Cheers, Tim On 13 Sep 2009, at 20:33, Naftoli Gugenheim wrote: I will try, G-d willing, to commit code today that allows you to bindSwitch -- that is, you give it a list of nodes, one of which is bound; and the others are replaced with NodeSeq.Empty. I used it in a view that had several parts that depend on the state. E.g., if you have not selected a client you see a search box with a button that either chooses a client if there's 1 result, or taked you to a search page. Once a client is selected, you see the clients info with a hyperlink to edit his info, and a button to unselect the client. So you could also use it for wizards. But there's also lift-wizard, which is a work in progress and may be more than what you need; I haven't looked at it myself. But my understanding is that there are usable pieces, it just needs to be polished and tied together. - Josh Suerethjoshua.suer...@gmail.com wrote: All, I write to you (unfortunately still) as a lift n00b. I'm trying to modify a form such that it looks more wizard like. i.e. I want it to specifically state You've completed part 1, you're on step 2 of 5, etc. How should I accomplish this in view-first rendering? Normal MVC, I'd make one controll that redirects you to the appropriate wizard screen depending on what steps have already been accomplished (i.e. the controller figures out which step you're on and sends you to the appropraite view. In Lift, I'm thinking I have a few options: 1) Have my stateful snippet actually return the various pages in code. I'm not happy with this, as my view would reside in the controller, but I could git'r'done this way. 2) Attempt to learn the lift-wizard library (is this stable/
[Lift] Re: Why isn't this a trait in lift-json?
On Sep 13, 3:15 pm, Joni Freeman freeman.j...@gmail.com wrote:
Hi,
That annotation is used to configure the json path when extracting
values. By default the extraction code assumes that case class
parameter names match with json field names. For instance these match:
case class Foo(bar: String, baz: Int)
{ bar: qwerty, baz: 10 }
But sometimes json field names can contain characters which are not
allowed in Scala identifiers. For example:
{ foo-bar: qwerty, baz: 10 }
Now, to able to extract this we have to somehow tell the extractor the
exact path explicitly. Currently @path annotation is used for that:
case class Foo(@path(foo-bar) bar: String, baz: Int)
I don't see how a trait can accomplish this, maybe I'm missing
something?
The reason why it is in Java is that Scala annotations are not
accessible at runtime.
Right but I'd also suggest removing Java code from Lift stack. The
above can be easily achieved by introducing a trait such as:
case class Foo(bar: String with Nominator, baz: Int)
Lift is a 100% Scala code with zero Java code. We also have strong
opinions in the team that we should stay away from annotations.
one option would be something like this:
Lift would have :
trait Nominator{
def name : String
}
In user's code:
case class Foo(bar: String with MyNominator, baz: Int)
trait MyNominator extends Nominator {
def name = foo-bar
}
Yes it is more verbose then the annotation but IMHO it is more Scala-
ish Lift-ish.
Cheers Joni
On Sep 13, 11:03 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Just had a browse over the latest commit and found the following in
path.java:
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface path {
public String value();
}
Any reason were not using a trait etc to complete the same
functionality?
Cheers, Tim
--~--~-~--~~~---~--~~
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: Getting Maven Offline Mode Working
Maven is essentially a java application, so you *should* just be able to download and run. I'm afraid I can't really give better advice for OS-X though. One other idea is to work with 1.1-M5, which should let you go offline on the older maven version - assuming you have no other snapshot dependencies. On Sun, Sep 13, 2009 at 10:51 PM, Peter Robinett pe...@bubblefoundry.comwrote: Thanks. I have version 2.0.9, which was installed by the Lift OS X installer. What is the best way to upgrade to 2.2.1? Peter On Sep 13, 12:57 pm, Kevin Wright kev.lee.wri...@googlemail.com wrote: Try updating to the latest maven, older versions have known issues with offline behaviour for snapshots. On Sun, Sep 13, 2009 at 8:55 PM, Peter Robinett pe...@bubblefoundry.com wrote: Hi all, I'm having problems running mvn -o jetty:run with my version of Lift (1.1-SNAPSHOT) because Maven thinks that net.liftweb:lift-core:jar:1.1- SNAPSHOT is missing. How do I fix that? My pom.xml is here: http://gist.github.com/186293 I've got an international plane flight in 24 hours, so I'd love to have offline mode working for then. Thanks for the help! Peter --~--~-~--~~~---~--~~ 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 deal breakers
+1 I would much prefer it if all JS were in external files (synthetic as necessary) and simply attached to the DOM via ids or classes. I have been building my sites this way for years, and I find it the best practice for reasons already put forth in this discussion. Chas. Timothy Perrett wrote: A synthetic file sounds good to me and would probably be preferable. Cheers, Tim On 13 Sep 2009, at 20:31, marius d. wrote: That looks a little cleaner but we'll have to look more into it if we'd want to go on this path. Perhaps accumulate those function into synthetic js file .. we'll see --~--~-~--~~~---~--~~ 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 deal breakers
If I understand everything correctly, the proposal is to dynamically create a js file for each page request to add event handlers? If this is true, then I'm against the proposal for the following two reasons: 1. Every page will load slower Since the js file is dynamically create on each request, the js file will be un-cacheable. This means the browser be will forced to make an addition HTTP request to the server to render each page. This adds roughly 150ms to the page load time (50ms to 200ms for network lag, 50ms for download, 10ms for js execution). 2. Each page will be more fragile Requiring the synthetic js file will add another point of failure. Even now-a-days with the ubiquity of broadband, connects still get lost and files still get corrupted. It's true that most modern web pages already depend a number of external JS and CSS files, but typically these files are static and easily cached. Just adding my 2 cents. -Xavi On Sun, Sep 13, 2009 at 5:41 PM, marius d. marius.dan...@gmail.com wrote: I think so too. Does anyone have an opinion against this? I'll probably have some time this week or next weekend to work on it. Br's, Marius On Sep 13, 2:59 pm, Timothy Perrett timo...@getintheloop.eu wrote: A synthetic file sounds good to me and would probably be preferable. Cheers, Tim On 13 Sep 2009, at 20:31, marius d. wrote: That looks a little cleaner but we'll have to look more into it if we'd want to go on this path. Perhaps accumulate those function into synthetic js file .. we'll see --~--~-~--~~~---~--~~ 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: Best way to write a wizard
Okay, here's what I mean.
Using chooseTemplate:
View:
...
person:code /
person:info
personinfo:concise
person:fullname /
bM:/b person:mobile /br /
/personinfo:concise
personinfo:detailed
Last: person:last /br /
First: person:first /br /
...
/personinfo:detailed
/person:info
Snippet:
bind(person, xhtml,
code - person.code.is,
info - ( if(!detailedView)
bind(person, chooseTemplate(xhtml, personinfo, concise),
...) // did I get the parameter order right? :)
else
bind(person, chooseTemplate(xhtml, personinfo, detailed), ...)
)
...
)
Using bindSwitch, with the implicit enabling bind chaining:
View:
person:code /
personinfo:concise
person:fullname /
bM:/b person:mobile /br /
/personinfo:concise
personinfo:detailed
Last: person:last /br /
First: person:first /br /
...
/personinfo:detailed
Snippet:
def bindDetailed: NodeSeq=NodeSeq = (ns: NodeSeq) = { ... }
xhtml.bind(person,
code - person.code.is
).bindSwitch(personinfo, Seq(concise, detailed)) (
if(detailedView)
1 - bindDetailed
else
0 - {(ns: NodeSeq) = ns.bind(person, fullname -
person.calcFullname(), ...)}
)
On Sun, Sep 13, 2009 at 5:46 PM, Naftoli Gugenheim naftoli...@gmail.com wrote:
By the way, I would be curious to see a link to a post where a newbie was
confused by multiple ways to do something -- not curious about the
difference, but having a harder time with even one than if there hadn't been
the alternative. I'm not doubting what you said--just curious to see such a
post.
-
Timothy Perretttimo...@getintheloop.eu wrote:
It just seems to me that you can already do what you detailed using
chooseTemplate? My concern about having multiple ways to do a single
task IMHO makes it more confusing for n00bs... Much better if there is
a clear problem:solution relationship :-) we already have
chooseTemplate right?
About wizard, you are right that is what dpp said - however, it's been
my experience of dave that if the comunity is discussing soemthing and
it keeps comming up (like the wizard) then he generally rolls his
sleeves up and gets the job done somehow!
Cheers, Tim
Sent from my iPhone
On 13 Sep 2009, at 21:35, Naftoli Gugenheim naftoli...@gmail.com
wrote:
What do you mean mixed messages?
Do you object to committing bindSwitch--after all it's much more
general and basic than wizards--or that it's what Josh should use?
Also, I read that DPP said it would take him 2-3 days once he found
2-3 days free to apply himself to lift-wizard. Did I miss a message
where he said that he found the time already?
-
Timothy Perretttimo...@getintheloop.eu wrote:
Naftoli,
Whilst I commend your idea of bindSwitch, im really not sure that is
the right way forward and would only confuse people (we dont want
mixed messages). DPP will in two days or less have the wizard in a
workable state so i would recommend doing just hanging out until that
is completed... by the sounds of it that will provide a much better
solution for Josh.
Cheers, Tim
On 13 Sep 2009, at 20:33, Naftoli Gugenheim wrote:
I will try, G-d willing, to commit code today that allows you to
bindSwitch -- that is, you give it a list of nodes, one of which
is bound; and the others are replaced with NodeSeq.Empty. I used it
in a view that had several parts that depend on the state. E.g., if
you have not selected a client you see a search box with a button
that either chooses a client if there's 1 result, or taked you to a
search page. Once a client is selected, you see the clients info
with a hyperlink to edit his info, and a button to unselect the
client.
So you could also use it for wizards. But there's also lift-wizard,
which is a work in progress and may be more than what you need; I
haven't looked at it myself. But my understanding is that there are
usable pieces, it just needs to be polished and tied together.
-
Josh Suerethjoshua.suer...@gmail.com wrote:
All,
I write to you (unfortunately still) as a lift n00b. I'm trying to
modify a
form such that it looks more wizard like. i.e. I want it to
specifically
state You've completed part 1, you're on step 2 of 5, etc.
How should I accomplish this in view-first rendering? Normal MVC,
I'd make
one controll that redirects you to the appropriate wizard screen
depending
on what steps have already been accomplished (i.e. the controller
figures
out which step you're on and sends you to the appropraite view.
In Lift, I'm thinking I have a few options:
1) Have my stateful snippet actually return the various pages in
code. I'm
not happy with this, as my view would reside in the controller, but
I could
git'r'done this way.
2) Attempt to learn the lift-wizard library (is this stable/
released?)
3) Spend more time
[Lift] Re: Getting Maven Offline Mode Working
You could probably just overwrite where ever the lift installer installed maven to. Or maybe run a newer lift installer? On Sun, Sep 13, 2009 at 7:00 PM, Kevin Wrightkev.lee.wri...@googlemail.com wrote: Maven is essentially a java application, so you *should* just be able to download and run. I'm afraid I can't really give better advice for OS-X though. One other idea is to work with 1.1-M5, which should let you go offline on the older maven version - assuming you have no other snapshot dependencies. On Sun, Sep 13, 2009 at 10:51 PM, Peter Robinett pe...@bubblefoundry.com wrote: Thanks. I have version 2.0.9, which was installed by the Lift OS X installer. What is the best way to upgrade to 2.2.1? Peter On Sep 13, 12:57 pm, Kevin Wright kev.lee.wri...@googlemail.com wrote: Try updating to the latest maven, older versions have known issues with offline behaviour for snapshots. On Sun, Sep 13, 2009 at 8:55 PM, Peter Robinett pe...@bubblefoundry.comwrote: Hi all, I'm having problems running mvn -o jetty:run with my version of Lift (1.1-SNAPSHOT) because Maven thinks that net.liftweb:lift-core:jar:1.1- SNAPSHOT is missing. How do I fix that? My pom.xml is here: http://gist.github.com/186293 I've got an international plane flight in 24 hours, so I'd love to have offline mode working for then. Thanks for the help! Peter --~--~-~--~~~---~--~~ 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 deal breakers
You mean cached by the browser? Isn't that a matter of setting headers, since it won't change in the session--or will it? Can one app switch dynamically from JQuery to YUI? - Xavi Ramirezxavi@gmail.com wrote: If I understand everything correctly, the proposal is to dynamically create a js file for each page request to add event handlers? If this is true, then I'm against the proposal for the following two reasons: 1. Every page will load slower Since the js file is dynamically create on each request, the js file will be un-cacheable. This means the browser be will forced to make an addition HTTP request to the server to render each page. This adds roughly 150ms to the page load time (50ms to 200ms for network lag, 50ms for download, 10ms for js execution). 2. Each page will be more fragile Requiring the synthetic js file will add another point of failure. Even now-a-days with the ubiquity of broadband, connects still get lost and files still get corrupted. It's true that most modern web pages already depend a number of external JS and CSS files, but typically these files are static and easily cached. Just adding my 2 cents. -Xavi On Sun, Sep 13, 2009 at 5:41 PM, marius d. marius.dan...@gmail.com wrote: I think so too. Does anyone have an opinion against this? I'll probably have some time this week or next weekend to work on it. Br's, Marius On Sep 13, 2:59?pm, Timothy Perrett timo...@getintheloop.eu wrote: A synthetic file sounds good to me and would probably be preferable. Cheers, Tim On 13 Sep 2009, at 20:31, marius d. wrote: That looks a little cleaner but we'll have to look more into it if we'd want to go on this path. Perhaps accumulate those function into synthetic js file .. we'll see --~--~-~--~~~---~--~~ 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: Getting Maven Offline Mode Working
Thanks, Kevin. Dropping in the latest version didn't seem to work (mvn --version kept saying I still had 2.0.9) but switching to 1.1-M5 did. Peter On Sep 13, 4:00 pm, Kevin Wright kev.lee.wri...@googlemail.com wrote: Maven is essentially a java application, so you *should* just be able to download and run. I'm afraid I can't really give better advice for OS-X though. One other idea is to work with 1.1-M5, which should let you go offline on the older maven version - assuming you have no other snapshot dependencies. On Sun, Sep 13, 2009 at 10:51 PM, Peter Robinett pe...@bubblefoundry.comwrote: Thanks. I have version 2.0.9, which was installed by the Lift OS X installer. What is the best way to upgrade to 2.2.1? Peter On Sep 13, 12:57 pm, Kevin Wright kev.lee.wri...@googlemail.com wrote: Try updating to the latest maven, older versions have known issues with offline behaviour for snapshots. On Sun, Sep 13, 2009 at 8:55 PM, Peter Robinett pe...@bubblefoundry.com wrote: Hi all, I'm having problems running mvn -o jetty:run with my version of Lift (1.1-SNAPSHOT) because Maven thinks that net.liftweb:lift-core:jar:1.1- SNAPSHOT is missing. How do I fix that? My pom.xml is here: http://gist.github.com/186293 I've got an international plane flight in 24 hours, so I'd love to have offline mode working for then. Thanks for the help! Peter --~--~-~--~~~---~--~~ 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 deal breakers
I kinda used the term js file a bit too loosely. It is true that each
page would likely have different functions there and even the same
page on subsequent load would have different content so the file can
not really be cached.
I'm thinking that instead of:
button onclick=liftAjax.lift_ajaxHandler
('F1029758482780OTA=true',null, null, null); return false;Press me/
button
We could have:
button onclick=liftAjax('F1029758482780OTA')Press me/button
...
.. and at the end of the page:
script type=text/javascript
function liftAjax(id) {
liftAjax.lift_ajaxHandler(id + '=true',null, null, null); return
false;
}
...
/script
Likely there will be more synthetic functions that would need to be
generated depending on specific cases. This approach would result in a
slightly larger markup but I'm not sure if the impact is negligible or
not. In essence we are replacing a function call with another one more
concise which helps just in having a more concise function calls in
the markup.
BUT most likely for functions like liftAjax above we should put them
in liftAjax.js that lift generates and those would just be helper
function. This means that the script block above will not be needed
anymore. Thoughts?
Thanks Xavi for the good points.
Br's,
Marius
On Sep 13, 7:03 pm, Xavi Ramirez xavi@gmail.com wrote:
If I understand everything correctly, the proposal is to dynamically
create a js file for each page request to add event handlers?
If this is true, then I'm against the proposal for the following two reasons:
1. Every page will load slower
Since the js file is dynamically create on each request, the js file
will be un-cacheable. This means the browser be will forced to make
an addition HTTP request to the server to render each page. This adds
roughly 150ms to the page load time (50ms to 200ms for network lag,
50ms for download, 10ms for js execution).
2. Each page will be more fragile
Requiring the synthetic js file will add another point of failure.
Even now-a-days with the ubiquity of broadband, connects still get
lost and files still get corrupted.
It's true that most modern web pages already depend a number of
external JS and CSS files, but typically these files are static and
easily cached.
Just adding my 2 cents.
-Xavi
On Sun, Sep 13, 2009 at 5:41 PM, marius d. marius.dan...@gmail.com wrote:
I think so too. Does anyone have an opinion against this? I'll
probably have some time this week or next weekend to work on it.
Br's,
Marius
On Sep 13, 2:59 pm, Timothy Perrett timo...@getintheloop.eu wrote:
A synthetic file sounds good to me and would probably be preferable.
Cheers, Tim
On 13 Sep 2009, at 20:31, marius d. wrote:
That looks a little cleaner but we'll have to look more into it if
we'd want to go on this path. Perhaps accumulate those function into
synthetic js file .. we'll see
--~--~-~--~~~---~--~~
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 deal breakers
I'm afraid I have to disagree. As a website developer, I've been putting all my JS into an external file (per page when necessary) for many years without any problems. Every good JS programmer I know does the same. It is considered *more* not less robust to put the JS in an external file and attach event handlers to the DOM from there. Page loading is in the eye of the beholder. Moving the JS to external scripts and the script tags to the bottom of the page actually makes the page appear more quickly, hence load faster in the mind of the user. Fragility is a non-issue. If the JS is all in the external file and the file does not load, then the page loads without JS. Put the event handlers in the HTML and the external file to which they refer doesn't load, same problem (except now you get a raft of JS errors). With best practices, the JS file can be cacheable, albeit per-page. Ideally, here's what I'd like. I add Lift tags to my page for each JS file I want included with the page. In each tag I designate whether that file is cacheable or dynamic and whether it is site-wide or specific to that page. Lift then takes all the site-wide cacheable pages, in the order I specified them, and gzips them up into a single file. Then it inserts a script tag for that file at the bottom of the page. Similarly, it takes all the page-specific cacheable pages, adds Lift's own page specific stuff at the end (the event handlers of which we speak), gzips it, gives it a name unique to that page, and adds another script tag for that file. Finally, it gzips up all dynamically-generated JS and gives it a timestamp for a filename so it won't be cached. This way I get jQuery, Ext JS, etc. all downloaded and cached in one big gzipped file. I get all page-specific but unchanging JS in another gzipped file for each page (cacheable, too). And I get my dynamically-generated, changing JS (if any) in a final gzipped file. My page is clean, all the scripts load in the proper order at the end, and everything is gzipped and, where applicable, cacheable for the best speed. We've just eliminated several points of failure, as I see it. Note also that since I use Ext JS, some of my JS files are very long and complex. I'm building a rich client, after all. I want to separate these scripts out into simple modules to make it easier to code them. But when they are served, I want them combined together in the proper order into one file. Another benefit of this system. On final option might be to indicate in the Lift tag whether the combined JS should be an external resource or inserted into the HTML page. Then you could insert the dynamic stuff into the page if you wanted to. (Of course, if nothing in the HTML changes, you've just prevented the caching of the HTML page, but it might be a useful option.) I wish I could offer to do this, but I'm desperately swamped at the moment (OK, forever). But this is what I would suggest as the best way to do things. Chas. Xavi Ramirez wrote: If I understand everything correctly, the proposal is to dynamically create a js file for each page request to add event handlers? If this is true, then I'm against the proposal for the following two reasons: 1. Every page will load slower Since the js file is dynamically create on each request, the js file will be un-cacheable. This means the browser be will forced to make an addition HTTP request to the server to render each page. This adds roughly 150ms to the page load time (50ms to 200ms for network lag, 50ms for download, 10ms for js execution). 2. Each page will be more fragile Requiring the synthetic js file will add another point of failure. Even now-a-days with the ubiquity of broadband, connects still get lost and files still get corrupted. It's true that most modern web pages already depend a number of external JS and CSS files, but typically these files are static and easily cached. Just adding my 2 cents. -Xavi On Sun, Sep 13, 2009 at 5:41 PM, marius d. marius.dan...@gmail.com wrote: I think so too. Does anyone have an opinion against this? I'll probably have some time this week or next weekend to work on it. Br's, Marius On Sep 13, 2:59 pm, Timothy Perrett timo...@getintheloop.eu wrote: A synthetic file sounds good to me and would probably be preferable. Cheers, Tim On 13 Sep 2009, at 20:31, marius d. wrote: That looks a little cleaner but we'll have to look more into it if we'd want to go on this path. Perhaps accumulate those function into synthetic js file .. we'll see --~--~-~--~~~---~--~~ 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 deal breakers
Is the DOM approach ruled out? I.e., generate a short script tag that is
generated from the events needed to be listened for, which are delegated to a
javascript generator that depends on the library. The actual JS files would be
static.
Maybe I missed where this option was eliminated?
Also, what did you mean by lucrative?
-
marius d.marius.dan...@gmail.com wrote:
I kinda used the term js file a bit too loosely. It is true that each
page would likely have different functions there and even the same
page on subsequent load would have different content so the file can
not really be cached.
I'm thinking that instead of:
button onclick=liftAjax.lift_ajaxHandler
('F1029758482780OTA=true',null, null, null); return false;Press me/
button
We could have:
button onclick=liftAjax('F1029758482780OTA')Press me/button
...
.. and at the end of the page:
script type=text/javascript
function liftAjax(id) {
liftAjax.lift_ajaxHandler(id + '=true',null, null, null); return
false;
}
...
/script
Likely there will be more synthetic functions that would need to be
generated depending on specific cases. This approach would result in a
slightly larger markup but I'm not sure if the impact is negligible or
not. In essence we are replacing a function call with another one more
concise which helps just in having a more concise function calls in
the markup.
BUT most likely for functions like liftAjax above we should put them
in liftAjax.js that lift generates and those would just be helper
function. This means that the script block above will not be needed
anymore. Thoughts?
Thanks Xavi for the good points.
Br's,
Marius
On Sep 13, 7:03?pm, Xavi Ramirez xavi@gmail.com wrote:
If I understand everything correctly, the proposal is to dynamically
create a js file for each page request to add event handlers?
If this is true, then I'm against the proposal for the following two reasons:
1. Every page will load slower
Since the js file is dynamically create on each request, the js file
will be un-cacheable. ?This means the browser be will forced to make
an addition HTTP request to the server to render each page. ?This adds
roughly 150ms to the page load time (50ms to 200ms for network lag,
50ms for download, 10ms for js execution).
2. Each page will be more fragile
Requiring the synthetic js file will add another point of failure.
Even now-a-days with the ubiquity of broadband, connects still get
lost and files still get corrupted.
It's true that most modern web pages already depend a number of
external JS and CSS files, but typically these files are static and
easily cached.
Just adding my 2 cents.
-Xavi
On Sun, Sep 13, 2009 at 5:41 PM, marius d. marius.dan...@gmail.com wrote:
I think so too. Does anyone have an opinion against this? I'll
probably have some time this week or next weekend to work on it.
Br's,
Marius
On Sep 13, 2:59?pm, Timothy Perrett timo...@getintheloop.eu wrote:
A synthetic file sounds good to me and would probably be preferable.
Cheers, Tim
On 13 Sep 2009, at 20:31, marius d. wrote:
That looks a little cleaner but we'll have to look more into it if
we'd want to go on this path. Perhaps accumulate those function into
synthetic js file .. we'll see
--~--~-~--~~~---~--~~
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 deal breakers
marius d. wrote:
I'm thinking that instead of:
button onclick=liftAjax.lift_ajaxHandler
('F1029758482780OTA=true',null, null, null); return false;Press me/
button
We could have:
button onclick=liftAjax('F1029758482780OTA')Press me/button
This is not what I had in mind at all. You still have the event handler
in the HTML. The idea, I thought, was to attach the event handler from
an external file using the id (or class) of the button element.
Maybe I'm living on a different planet (a distinct possibility and one
I've been giving much thought to recently), but virtually every JS
programmer I know considers this a best practice, and it has been
considered so for many years.
Frankly, and maybe I'm just a bit dull, but I can't conceive of what the
advantage to the above change might be. What am I missing?
Chas.
--~--~-~--~~~---~--~~
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: Why isn't this a trait in lift-json?
Scala does support annotations, they're just anemic at this point.
I hadn't tried, but does extending ClassfileAnnotation allow runtime
visibility? That would give you a pure scala implementation. If not, I
think we need to rally for StaticAnnotation/ClassfileAnnotation to be joined
by their future brother RuntimeAnnotation.
- Josh
On Sun, Sep 13, 2009 at 6:31 PM, marius d. marius.dan...@gmail.com wrote:
On Sep 13, 3:15 pm, Joni Freeman freeman.j...@gmail.com wrote:
Hi,
That annotation is used to configure the json path when extracting
values. By default the extraction code assumes that case class
parameter names match with json field names. For instance these match:
case class Foo(bar: String, baz: Int)
{ bar: qwerty, baz: 10 }
But sometimes json field names can contain characters which are not
allowed in Scala identifiers. For example:
{ foo-bar: qwerty, baz: 10 }
Now, to able to extract this we have to somehow tell the extractor the
exact path explicitly. Currently @path annotation is used for that:
case class Foo(@path(foo-bar) bar: String, baz: Int)
I don't see how a trait can accomplish this, maybe I'm missing
something?
The reason why it is in Java is that Scala annotations are not
accessible at runtime.
Right but I'd also suggest removing Java code from Lift stack. The
above can be easily achieved by introducing a trait such as:
case class Foo(bar: String with Nominator, baz: Int)
Lift is a 100% Scala code with zero Java code. We also have strong
opinions in the team that we should stay away from annotations.
one option would be something like this:
Lift would have :
trait Nominator{
def name : String
}
In user's code:
case class Foo(bar: String with MyNominator, baz: Int)
trait MyNominator extends Nominator {
def name = foo-bar
}
Yes it is more verbose then the annotation but IMHO it is more Scala-
ish Lift-ish.
Cheers Joni
On Sep 13, 11:03 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Just had a browse over the latest commit and found the following in
path.java:
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface path {
public String value();
}
Any reason were not using a trait etc to complete the same
functionality?
Cheers, Tim
--~--~-~--~~~---~--~~
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: Getting Maven Offline Mode Working
Check your PATH variable, probably pointing to the wrong maven still. You really need to get off of maven 2.0.9. The offlline mode is broken. 2.0.10 should be the minimum version you need to fix that issue. On Sun, Sep 13, 2009 at 8:33 PM, Peter Robinett pe...@bubblefoundry.comwrote: Thanks, Kevin. Dropping in the latest version didn't seem to work (mvn --version kept saying I still had 2.0.9) but switching to 1.1-M5 did. Peter On Sep 13, 4:00 pm, Kevin Wright kev.lee.wri...@googlemail.com wrote: Maven is essentially a java application, so you *should* just be able to download and run. I'm afraid I can't really give better advice for OS-X though. One other idea is to work with 1.1-M5, which should let you go offline on the older maven version - assuming you have no other snapshot dependencies. On Sun, Sep 13, 2009 at 10:51 PM, Peter Robinett pe...@bubblefoundry.comwrote: Thanks. I have version 2.0.9, which was installed by the Lift OS X installer. What is the best way to upgrade to 2.2.1? Peter On Sep 13, 12:57 pm, Kevin Wright kev.lee.wri...@googlemail.com wrote: Try updating to the latest maven, older versions have known issues with offline behaviour for snapshots. On Sun, Sep 13, 2009 at 8:55 PM, Peter Robinett pe...@bubblefoundry.com wrote: Hi all, I'm having problems running mvn -o jetty:run with my version of Lift (1.1-SNAPSHOT) because Maven thinks that net.liftweb:lift-core:jar:1.1- SNAPSHOT is missing. How do I fix that? My pom.xml is here: http://gist.github.com/186293 I've got an international plane flight in 24 hours, so I'd love to have offline mode working for then. Thanks for the help! Peter --~--~-~--~~~---~--~~ 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 deal breakers
This is how we do JavaScript/ExtJS development at my work place, except with a twist. We actually have a javascript-only project for a our javascript library. We use the maven-javascript-tools plugins to create a javascript project that relies on others (in our case, things like Simile Timeline and ExtJS). We then compile/minify the javascript into an 'artifact' that gets used by our main webapp, where the alchim yui-compressor takes all the CSS/Javascript and bundles as much of it as possible into a single huge JS file. The library project can make use of JSUnit tests (slow-to-run, recommend for integration tests only), and has its own stubbed out controllers and jetty for testing. It's a very interesting setup, but I'm very happy with it. We have very modular JS code, and very very very very very very little JSP/HTML code (we didn't select lift at work). If I were to start using Lift for my backend to ExtJS I would need support for a similar setup (i.e. expect little or no HTML generated outside of the Javascript). Also, the ability to cache dynamically created pages works great for our product in production, however, we're only dynamically creating a javasript file containing very static resources (externalized string library for use when rendering in javascript. This ensures our Javascript and Java externalization works similarly.) I highly recommend the approach if using something like ExtJS, however for lift's templates I'd agree that a page-unique-id would be required for every synthetically created js file so that caching works appropriately. You can also force the browser to check if something's changed. We have a development hack that checks class-load time of the synthetic-js-generator and ensures the cached copy is up-to-date from that time. This means jetty-reloads will reload the class and ensure the next refresh pulls a new version. It's a bit tricky to get set up at first, but worked great! Hopefully this input is helpful! - Josh On Sun, Sep 13, 2009 at 8:48 PM, Charles F. Munat c...@munat.com wrote: I'm afraid I have to disagree. As a website developer, I've been putting all my JS into an external file (per page when necessary) for many years without any problems. Every good JS programmer I know does the same. It is considered *more* not less robust to put the JS in an external file and attach event handlers to the DOM from there. Page loading is in the eye of the beholder. Moving the JS to external scripts and the script tags to the bottom of the page actually makes the page appear more quickly, hence load faster in the mind of the user. Fragility is a non-issue. If the JS is all in the external file and the file does not load, then the page loads without JS. Put the event handlers in the HTML and the external file to which they refer doesn't load, same problem (except now you get a raft of JS errors). With best practices, the JS file can be cacheable, albeit per-page. Ideally, here's what I'd like. I add Lift tags to my page for each JS file I want included with the page. In each tag I designate whether that file is cacheable or dynamic and whether it is site-wide or specific to that page. Lift then takes all the site-wide cacheable pages, in the order I specified them, and gzips them up into a single file. Then it inserts a script tag for that file at the bottom of the page. Similarly, it takes all the page-specific cacheable pages, adds Lift's own page specific stuff at the end (the event handlers of which we speak), gzips it, gives it a name unique to that page, and adds another script tag for that file. Finally, it gzips up all dynamically-generated JS and gives it a timestamp for a filename so it won't be cached. This way I get jQuery, Ext JS, etc. all downloaded and cached in one big gzipped file. I get all page-specific but unchanging JS in another gzipped file for each page (cacheable, too). And I get my dynamically-generated, changing JS (if any) in a final gzipped file. My page is clean, all the scripts load in the proper order at the end, and everything is gzipped and, where applicable, cacheable for the best speed. We've just eliminated several points of failure, as I see it. Note also that since I use Ext JS, some of my JS files are very long and complex. I'm building a rich client, after all. I want to separate these scripts out into simple modules to make it easier to code them. But when they are served, I want them combined together in the proper order into one file. Another benefit of this system. On final option might be to indicate in the Lift tag whether the combined JS should be an external resource or inserted into the HTML page. Then you could insert the dynamic stuff into the page if you wanted to. (Of course, if nothing in the HTML changes, you've just prevented the caching of the HTML page, but it might be a useful option.) I wish I could offer to do this, but I'm desperately
[Lift] Re: Lift deal breakers
Hi Marius,
Ahh yes I see. That's very different from what I originally
understood. Your implementation makes sense.
Thanks,
Xavi
On Sun, Sep 13, 2009 at 8:43 PM, marius d. marius.dan...@gmail.com wrote:
I kinda used the term js file a bit too loosely. It is true that each
page would likely have different functions there and even the same
page on subsequent load would have different content so the file can
not really be cached.
I'm thinking that instead of:
button onclick=liftAjax.lift_ajaxHandler
('F1029758482780OTA=true',null, null, null); return false;Press me/
button
We could have:
button onclick=liftAjax('F1029758482780OTA')Press me/button
...
.. and at the end of the page:
script type=text/javascript
function liftAjax(id) {
liftAjax.lift_ajaxHandler(id + '=true',null, null, null); return
false;
}
...
/script
Likely there will be more synthetic functions that would need to be
generated depending on specific cases. This approach would result in a
slightly larger markup but I'm not sure if the impact is negligible or
not. In essence we are replacing a function call with another one more
concise which helps just in having a more concise function calls in
the markup.
BUT most likely for functions like liftAjax above we should put them
in liftAjax.js that lift generates and those would just be helper
function. This means that the script block above will not be needed
anymore. Thoughts?
Thanks Xavi for the good points.
Br's,
Marius
On Sep 13, 7:03 pm, Xavi Ramirez xavi@gmail.com wrote:
If I understand everything correctly, the proposal is to dynamically
create a js file for each page request to add event handlers?
If this is true, then I'm against the proposal for the following two reasons:
1. Every page will load slower
Since the js file is dynamically create on each request, the js file
will be un-cacheable. This means the browser be will forced to make
an addition HTTP request to the server to render each page. This adds
roughly 150ms to the page load time (50ms to 200ms for network lag,
50ms for download, 10ms for js execution).
2. Each page will be more fragile
Requiring the synthetic js file will add another point of failure.
Even now-a-days with the ubiquity of broadband, connects still get
lost and files still get corrupted.
It's true that most modern web pages already depend a number of
external JS and CSS files, but typically these files are static and
easily cached.
Just adding my 2 cents.
-Xavi
On Sun, Sep 13, 2009 at 5:41 PM, marius d. marius.dan...@gmail.com wrote:
I think so too. Does anyone have an opinion against this? I'll
probably have some time this week or next weekend to work on it.
Br's,
Marius
On Sep 13, 2:59 pm, Timothy Perrett timo...@getintheloop.eu wrote:
A synthetic file sounds good to me and would probably be preferable.
Cheers, Tim
On 13 Sep 2009, at 20:31, marius d. wrote:
That looks a little cleaner but we'll have to look more into it if
we'd want to go on this path. Perhaps accumulate those function into
synthetic js file .. we'll see
--~--~-~--~~~---~--~~
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 deal breakers
On Sep 13, 8:00 pm, Charles F. Munat c...@munat.com wrote:
marius d. wrote:
I'm thinking that instead of:
button onclick=liftAjax.lift_ajaxHandler
('F1029758482780OTA=true',null, null, null); return false;Press me/
button
We could have:
button onclick=liftAjax('F1029758482780OTA')Press me/button
This is not what I had in mind at all. You still have the event handler
in the HTML. The idea, I thought, was to attach the event handler from
an external file using the id (or class) of the button element.
I understand that but this is a bit impractical because lift would
have to generate artificial ID-s OR id-s could be tampered with or
other JS libraries may generate their own ID-s etc. Selectors by class
is also a little impractical from a framework standpoint. Also we'd
have to add code for each underlying JS library (JQuery, YUI etc).
This would require IMHO significant code to write and not a
significant gain. But I'd love to prove me wrong.
Maybe I'm living on a different planet (a distinct possibility and one
I've been giving much thought to recently), but virtually every JS
programmer I know considers this a best practice, and it has been
considered so for many years.
I know this is practical from applications perspective when writing
specific JS etc. but from a framework perspective, this is not.
Frankly, and maybe I'm just a bit dull, but I can't conceive of what the
advantage to the above change might be. What am I missing?
I'm not 100% buying any proposal so far ... as I explained above the
disadvantages as we replace a JS expression with another JS function
call. It just adds a bit of conciseness .. nothing more.
Chas.
--~--~-~--~~~---~--~~
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 deal breakers
Well, conciseness is always good. I haven't looked at (and don't have
time to look at) the code that inserts this stuff, so I'll take your
word for it that it's a big undertaking. Lord knows, I don't have time,
so I'm certainly not complaining.
But we've got a desideratum, anyway. Maybe down the road someone will
have time to look at it.
Thanks for the clarification!
Chas.
marius d. wrote:
On Sep 13, 8:00 pm, Charles F. Munat c...@munat.com wrote:
marius d. wrote:
I'm thinking that instead of:
button onclick=liftAjax.lift_ajaxHandler
('F1029758482780OTA=true',null, null, null); return false;Press me/
button
We could have:
button onclick=liftAjax('F1029758482780OTA')Press me/button
This is not what I had in mind at all. You still have the event handler
in the HTML. The idea, I thought, was to attach the event handler from
an external file using the id (or class) of the button element.
I understand that but this is a bit impractical because lift would
have to generate artificial ID-s OR id-s could be tampered with or
other JS libraries may generate their own ID-s etc. Selectors by class
is also a little impractical from a framework standpoint. Also we'd
have to add code for each underlying JS library (JQuery, YUI etc).
This would require IMHO significant code to write and not a
significant gain. But I'd love to prove me wrong.
Maybe I'm living on a different planet (a distinct possibility and one
I've been giving much thought to recently), but virtually every JS
programmer I know considers this a best practice, and it has been
considered so for many years.
I know this is practical from applications perspective when writing
specific JS etc. but from a framework perspective, this is not.
Frankly, and maybe I'm just a bit dull, but I can't conceive of what the
advantage to the above change might be. What am I missing?
I'm not 100% buying any proposal so far ... as I explained above the
disadvantages as we replace a JS expression with another JS function
call. It just adds a bit of conciseness .. nothing more.
Chas.
--~--~-~--~~~---~--~~
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 deal breakers
This is pretty close to what I'm doing. I have a REST backend (in Lift) that serves the data, and a separate Ext JS front end (one single page with a lot of Ext JS) running in a separate Lift app. It's still in progress and I haven't worked out all the details yet, but I'm very happy with it so far. It has really simplified things. The difficult part is authentication/authorization. Ugh. I, too, am planning to combine and minimize my cacheable JS files when it goes live. Sounds like your system is much more sophisticated... Chas. Josh Suereth wrote: This is how we do JavaScript/ExtJS development at my work place, except with a twist. We actually have a javascript-only project for a our javascript library. We use the maven-javascript-tools plugins to create a javascript project that relies on others (in our case, things like Simile Timeline and ExtJS). We then compile/minify the javascript into an 'artifact' that gets used by our main webapp, where the alchim yui-compressor takes all the CSS/Javascript and bundles as much of it as possible into a single huge JS file. The library project can make use of JSUnit tests (slow-to-run, recommend for integration tests only), and has its own stubbed out controllers and jetty for testing. It's a very interesting setup, but I'm very happy with it. We have very modular JS code, and very very very very very very little JSP/HTML code (we didn't select lift at work). If I were to start using Lift for my backend to ExtJS I would need support for a similar setup (i.e. expect little or no HTML generated outside of the Javascript). Also, the ability to cache dynamically created pages works great for our product in production, however, we're only dynamically creating a javasript file containing very static resources (externalized string library for use when rendering in javascript. This ensures our Javascript and Java externalization works similarly.) I highly recommend the approach if using something like ExtJS, however for lift's templates I'd agree that a page-unique-id would be required for every synthetically created js file so that caching works appropriately. You can also force the browser to check if something's changed. We have a development hack that checks class-load time of the synthetic-js-generator and ensures the cached copy is up-to-date from that time. This means jetty-reloads will reload the class and ensure the next refresh pulls a new version. It's a bit tricky to get set up at first, but worked great! Hopefully this input is helpful! - Josh On Sun, Sep 13, 2009 at 8:48 PM, Charles F. Munat c...@munat.com mailto:c...@munat.com wrote: I'm afraid I have to disagree. As a website developer, I've been putting all my JS into an external file (per page when necessary) for many years without any problems. Every good JS programmer I know does the same. It is considered *more* not less robust to put the JS in an external file and attach event handlers to the DOM from there. Page loading is in the eye of the beholder. Moving the JS to external scripts and the script tags to the bottom of the page actually makes the page appear more quickly, hence load faster in the mind of the user. Fragility is a non-issue. If the JS is all in the external file and the file does not load, then the page loads without JS. Put the event handlers in the HTML and the external file to which they refer doesn't load, same problem (except now you get a raft of JS errors). With best practices, the JS file can be cacheable, albeit per-page. Ideally, here's what I'd like. I add Lift tags to my page for each JS file I want included with the page. In each tag I designate whether that file is cacheable or dynamic and whether it is site-wide or specific to that page. Lift then takes all the site-wide cacheable pages, in the order I specified them, and gzips them up into a single file. Then it inserts a script tag for that file at the bottom of the page. Similarly, it takes all the page-specific cacheable pages, adds Lift's own page specific stuff at the end (the event handlers of which we speak), gzips it, gives it a name unique to that page, and adds another script tag for that file. Finally, it gzips up all dynamically-generated JS and gives it a timestamp for a filename so it won't be cached. This way I get jQuery, Ext JS, etc. all downloaded and cached in one big gzipped file. I get all page-specific but unchanging JS in another gzipped file for each page (cacheable, too). And I get my dynamically-generated, changing JS (if any) in a final gzipped file. My page is clean, all the scripts load in the proper order at the end, and everything is gzipped and, where applicable, cacheable for the best speed. We've
[Lift] Ajax example from the book
Could somebody please explain to me how this example from the book
works.
def myFunc(html:NodeSeq):NodeSeq = {
bind(hello,html,button -
ajaxButton(Text(Press me),
{ () =
println(Got an Ajax call.)
SetHtml(my-div, Text(That's it))
})
)
}
In particular, what do I pass in as the html parameter?
What is 'hello'?
How does the div work?
I don't understand 'bind'.
--~--~-~--~~~---~--~~
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] Using Ajax to send text to browser as it is generated.
I have some code that generates a list of urls but it takes awhile to generate all of them. I would like to send them to the browser as they are generated. How do I use Ajax to accomplish this. I can put the urls in a List as they are generated if that works. But how do I hook up the List to the Ajax code. I do not understand the ajax examples in the book. Thanks. --~--~-~--~~~---~--~~ 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: Why isn't this a trait in lift-json?
Extending ClassfileAnnotation does not work at the moment. Excerpt
from Programming Scala (http://programming-scala.labs.oreilly.com/
ch13.html):
Another child of scala.Annotation that is intended to be a parent of
other annotations is the trait scala.ClassfileAnnotation. It is
supposed to be used for annotations that should have runtime
retention, i.e., the annotations should be visible in the class file
so they are available at runtime. However, actually using it with the
JDK version of Scala results in compiler errors Hence, if you
want runtime visibility, you have to implement the annotation in
Java.
Cheers Joni
On Sep 14, 4:18 am, Josh Suereth joshua.suer...@gmail.com wrote:
Scala does support annotations, they're just anemic at this point.
I hadn't tried, but does extending ClassfileAnnotation allow runtime
visibility? That would give you a pure scala implementation. If not, I
think we need to rally for StaticAnnotation/ClassfileAnnotation to be joined
by their future brother RuntimeAnnotation.
- Josh
On Sun, Sep 13, 2009 at 6:31 PM, marius d. marius.dan...@gmail.com wrote:
On Sep 13, 3:15 pm, Joni Freeman freeman.j...@gmail.com wrote:
Hi,
That annotation is used to configure the json path when extracting
values. By default the extraction code assumes that case class
parameter names match with json field names. For instance these match:
case class Foo(bar: String, baz: Int)
{ bar: qwerty, baz: 10 }
But sometimes json field names can contain characters which are not
allowed in Scala identifiers. For example:
{ foo-bar: qwerty, baz: 10 }
Now, to able to extract this we have to somehow tell the extractor the
exact path explicitly. Currently @path annotation is used for that:
case class Foo(@path(foo-bar) bar: String, baz: Int)
I don't see how a trait can accomplish this, maybe I'm missing
something?
The reason why it is in Java is that Scala annotations are not
accessible at runtime.
Right but I'd also suggest removing Java code from Lift stack. The
above can be easily achieved by introducing a trait such as:
case class Foo(bar: String with Nominator, baz: Int)
Lift is a 100% Scala code with zero Java code. We also have strong
opinions in the team that we should stay away from annotations.
one option would be something like this:
Lift would have :
trait Nominator{
def name : String
}
In user's code:
case class Foo(bar: String with MyNominator, baz: Int)
trait MyNominator extends Nominator {
def name = foo-bar
}
Yes it is more verbose then the annotation but IMHO it is more Scala-
ish Lift-ish.
Cheers Joni
On Sep 13, 11:03 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Just had a browse over the latest commit and found the following in
path.java:
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface path {
public String value();
}
Any reason were not using a trait etc to complete the same
functionality?
Cheers, Tim
--~--~-~--~~~---~--~~
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: Why isn't this a trait in lift-json?
Is there a list of rules for committers to stick to? Especially considering the
review board system being put into place.
-
Joni Freemanfreeman.j...@gmail.com wrote:
Extending ClassfileAnnotation does not work at the moment. Excerpt
from Programming Scala (http://programming-scala.labs.oreilly.com/
ch13.html):
Another child of scala.Annotation that is intended to be a parent of
other annotations is the trait scala.ClassfileAnnotation. It is
supposed to be used for annotations that should have runtime
retention, i.e., the annotations should be visible in the class file
so they are available at runtime. However, actually using it with the
JDK version of Scala results in compiler errors Hence, if you
want runtime visibility, you have to implement the annotation in
Java.
Cheers Joni
On Sep 14, 4:18?am, Josh Suereth joshua.suer...@gmail.com wrote:
Scala does support annotations, they're just anemic at this point.
I hadn't tried, but does extending ClassfileAnnotation allow runtime
visibility? ?That would give you a pure scala implementation. ?If not, I
think we need to rally for StaticAnnotation/ClassfileAnnotation to be joined
by their future brother RuntimeAnnotation.
- Josh
On Sun, Sep 13, 2009 at 6:31 PM, marius d. marius.dan...@gmail.com wrote:
On Sep 13, 3:15 pm, Joni Freeman freeman.j...@gmail.com wrote:
Hi,
That annotation is used to configure the json path when extracting
values. By default the extraction code assumes that case class
parameter names match with json field names. For instance these match:
case class Foo(bar: String, baz: Int)
{ bar: qwerty, baz: 10 }
But sometimes json field names can contain characters which are not
allowed in Scala identifiers. For example:
{ foo-bar: qwerty, baz: 10 }
Now, to able to extract this we have to somehow tell the extractor the
exact path explicitly. Currently @path annotation is used for that:
case class Foo(@path(foo-bar) bar: String, baz: Int)
I don't see how a trait can accomplish this, maybe I'm missing
something?
The reason why it is in Java is that Scala annotations are not
accessible at ?runtime.
Right but I'd also suggest removing Java code from Lift stack. The
above can be easily achieved by introducing a trait such as:
case class Foo(bar: String with Nominator, baz: Int)
Lift is a 100% Scala code with zero Java code. We also have strong
opinions in the team that we should stay away from annotations.
one option would be something like this:
Lift would have :
trait Nominator{
?def name : String
}
In user's code:
case class Foo(bar: String with MyNominator, baz: Int)
trait MyNominator extends Nominator {
?def name = foo-bar
}
Yes it is more verbose then the annotation but IMHO it is more Scala-
ish Lift-ish.
Cheers Joni
On Sep 13, 11:03 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Just had a browse over the latest commit and found the following in
path.java:
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface path {
? ? public String value();
}
Any reason were not using a trait etc to complete the same
functionality?
Cheers, Tim
--~--~-~--~~~---~--~~
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: Why isn't this a trait in lift-json?
Hi,
Here's another example.
{lotto:
{
id: 5,
winning-numbers: [2,45,34,23,7,5,3],
draw-date: 2009-09-14T18:00:00Z,
winners: [
{winner-id: 23, numbers: [2,45,34,23,3,5] },
{winner-id: 54, numbers:[52,3,12,11,18,22] }
]
}
}
At the moment I'm extracting this with following case class structure.
case class Winner(@path(winner-id) id: Long, numbers: List[Int])
case class Lotto(id: Long, @path(winning-numbers) winningNumbers:
List[Int], winners: List[Winner],
@path(draw-date) drawDate: Option[Date])
Using a trait approach it would be something like:
case class Winner(id: Long with WinnerIdNominator, numbers: List[Int])
case class Lotto(id: Long, winningNumbers: List[Int] with
WinningNumbersNominator, winners: List[Winner],
drawDate: Option[Date] with DrawDateNominator)
trait WinnerIdNominator extends Nominator {
def name = winner-id
}
trait WinningNumbersNominator extends Nominator {
def name = winning-numbers
}
trait DrawDateNominator extends Nominator {
def name = draw-date
}
Now, there's some problems.
1. Mixin a trait with a primitive fails:
scala case class Winner(id: Long with WinnerIdNominator, numbers: List
[Int])
console:5: error: ambiguous reference to overloaded definition,
both method == in class Object of type (AnyRef)Boolean
and method == in class Long of type (Long)Boolean
match argument types (Long with WinnerIdNominator)
case class Winner(id: Long with WinnerIdNominator, numbers: List
[Int])
2. How to get access to Nominator.name using reflection?
When extracting values we have json and type of target instance, in
this example classOf[Lotto]. It is not clear to me how those traits
should be reflected at runtime.
Cheers Joni
On Sep 14, 1:31 am, marius d. marius.dan...@gmail.com wrote:
On Sep 13, 3:15 pm, Joni Freeman freeman.j...@gmail.com wrote:
Hi,
That annotation is used to configure the json path when extracting
values. By default the extraction code assumes that case class
parameter names match with json field names. For instance these match:
case class Foo(bar: String, baz: Int)
{ bar: qwerty, baz: 10 }
But sometimes json field names can contain characters which are not
allowed in Scala identifiers. For example:
{ foo-bar: qwerty, baz: 10 }
Now, to able to extract this we have to somehow tell the extractor the
exact path explicitly. Currently @path annotation is used for that:
case class Foo(@path(foo-bar) bar: String, baz: Int)
I don't see how a trait can accomplish this, maybe I'm missing
something?
The reason why it is in Java is that Scala annotations are not
accessible at runtime.
Right but I'd also suggest removing Java code from Lift stack. The
above can be easily achieved by introducing a trait such as:
case class Foo(bar: String with Nominator, baz: Int)
Lift is a 100% Scala code with zero Java code. We also have strong
opinions in the team that we should stay away from annotations.
one option would be something like this:
Lift would have :
trait Nominator{
def name : String
}
In user's code:
case class Foo(bar: String with MyNominator, baz: Int)
trait MyNominator extends Nominator {
def name = foo-bar
}
Yes it is more verbose then the annotation but IMHO it is more Scala-
ish Lift-ish.
Cheers Joni
On Sep 13, 11:03 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Just had a browse over the latest commit and found the following in
path.java:
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface path {
public String value();
}
Any reason were not using a trait etc to complete the same
functionality?
Cheers, Tim
--~--~-~--~~~---~--~~
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: Why isn't this a trait in lift-json?
Can't you require back ticks and name the case class members the same as in the
JSON?
Also if it comes to traits you may as well just allow an adapter that can read
and write values -- maybe a map of String to setter/getter functions.
-
Joni Freemanfreeman.j...@gmail.com wrote:
Hi,
Here's another example.
{lotto:
{
id: 5,
winning-numbers: [2,45,34,23,7,5,3],
draw-date: 2009-09-14T18:00:00Z,
winners: [
{winner-id: 23, numbers: [2,45,34,23,3,5] },
{winner-id: 54, numbers:[52,3,12,11,18,22] }
]
}
}
At the moment I'm extracting this with following case class structure.
case class Winner(@path(winner-id) id: Long, numbers: List[Int])
case class Lotto(id: Long, @path(winning-numbers) winningNumbers:
List[Int], winners: List[Winner],
@path(draw-date) drawDate: Option[Date])
Using a trait approach it would be something like:
case class Winner(id: Long with WinnerIdNominator, numbers: List[Int])
case class Lotto(id: Long, winningNumbers: List[Int] with
WinningNumbersNominator, winners: List[Winner],
drawDate: Option[Date] with DrawDateNominator)
trait WinnerIdNominator extends Nominator {
def name = winner-id
}
trait WinningNumbersNominator extends Nominator {
def name = winning-numbers
}
trait DrawDateNominator extends Nominator {
def name = draw-date
}
Now, there's some problems.
1. Mixin a trait with a primitive fails:
scala case class Winner(id: Long with WinnerIdNominator, numbers: List
[Int])
console:5: error: ambiguous reference to overloaded definition,
both method == in class Object of type (AnyRef)Boolean
and method == in class Long of type (Long)Boolean
match argument types (Long with WinnerIdNominator)
case class Winner(id: Long with WinnerIdNominator, numbers: List
[Int])
2. How to get access to Nominator.name using reflection?
When extracting values we have json and type of target instance, in
this example classOf[Lotto]. It is not clear to me how those traits
should be reflected at runtime.
Cheers Joni
On Sep 14, 1:31?am, marius d. marius.dan...@gmail.com wrote:
On Sep 13, 3:15?pm, Joni Freeman freeman.j...@gmail.com wrote:
Hi,
That annotation is used to configure the json path when extracting
values. By default the extraction code assumes that case class
parameter names match with json field names. For instance these match:
case class Foo(bar: String, baz: Int)
{ bar: qwerty, baz: 10 }
But sometimes json field names can contain characters which are not
allowed in Scala identifiers. For example:
{ foo-bar: qwerty, baz: 10 }
Now, to able to extract this we have to somehow tell the extractor the
exact path explicitly. Currently @path annotation is used for that:
case class Foo(@path(foo-bar) bar: String, baz: Int)
I don't see how a trait can accomplish this, maybe I'm missing
something?
The reason why it is in Java is that Scala annotations are not
accessible at ?runtime.
Right but I'd also suggest removing Java code from Lift stack. The
above can be easily achieved by introducing a trait such as:
case class Foo(bar: String with Nominator, baz: Int)
Lift is a 100% Scala code with zero Java code. We also have strong
opinions in the team that we should stay away from annotations.
one option would be something like this:
Lift would have :
trait Nominator{
? def name : String
}
In user's code:
case class Foo(bar: String with MyNominator, baz: Int)
trait MyNominator extends Nominator {
?def name = foo-bar
}
Yes it is more verbose then the annotation but IMHO it is more Scala-
ish Lift-ish.
Cheers Joni
On Sep 13, 11:03?pm, Timothy Perrett timo...@getintheloop.eu wrote:
Just had a browse over the latest commit and found the following in
path.java:
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface path {
? ? public String value();
}
Any reason were not using a trait etc to complete the same
functionality?
Cheers, Tim
--~--~-~--~~~---~--~~
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: Why isn't this a trait in lift-json?
Using back ticks could work, I'll have to check that out. Another
approach is to use map function, it works but there's a small
performance and verbosity hit.
import net.liftweb.json.JsonParser.parse
import net.liftweb.json.JsonAST.JField
implicit val formats = net.liftweb.json.DefaultFormats
case class Winner(id: Long, numbers: List[Int])
case class Lotto(id: Long, winningNumbers: List[Int], winners: List
[Winner],
drawDate: Option[java.util.Date])
val json = parse(
{lotto:
{
id: 5,
winning-numbers: [2,45,34,23,7,5,3],
draw-date: 2009-09-14T18:00:00Z,
winners: [
{winner-id: 23, numbers: [2,45,34,23,3,5] },
{winner-id: 54, numbers:[52,3,12,11,18,22] }
]
}
}
)
val json2 = json map {
case JField(winning-numbers, x) = JField(winningNumbers, x)
case JField(draw-date, x) = JField(drawDate, x)
case JField(winning-id, x) = JField(id, x)
case x = x
}
json2.extract[Lotto]
So, I can remove @path feature (and maybe reintroduce it when Scala
gets runtime visible annotations) if the community feels that Java
annotations should not be used.
Cheers Joni
On Sep 14, 8:14 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
Can't you require back ticks and name the case class members the same as in
the JSON?
Also if it comes to traits you may as well just allow an adapter that can
read and write values -- maybe a map of String to setter/getter functions.
-
Joni Freemanfreeman.j...@gmail.com wrote:
Hi,
Here's another example.
{lotto:
{
id: 5,
winning-numbers: [2,45,34,23,7,5,3],
draw-date: 2009-09-14T18:00:00Z,
winners: [
{winner-id: 23, numbers: [2,45,34,23,3,5] },
{winner-id: 54, numbers:[52,3,12,11,18,22] }
]
}
}
At the moment I'm extracting this with following case class structure.
case class Winner(@path(winner-id) id: Long, numbers: List[Int])
case class Lotto(id: Long, @path(winning-numbers) winningNumbers:
List[Int], winners: List[Winner],
�...@path(draw-date) drawDate: Option[Date])
Using a trait approach it would be something like:
case class Winner(id: Long with WinnerIdNominator, numbers: List[Int])
case class Lotto(id: Long, winningNumbers: List[Int] with
WinningNumbersNominator, winners: List[Winner],
drawDate: Option[Date] with DrawDateNominator)
trait WinnerIdNominator extends Nominator {
def name = winner-id
}
trait WinningNumbersNominator extends Nominator {
def name = winning-numbers
}
trait DrawDateNominator extends Nominator {
def name = draw-date
}
Now, there's some problems.
1. Mixin a trait with a primitive fails:
scala case class Winner(id: Long with WinnerIdNominator, numbers: List
[Int])
console:5: error: ambiguous reference to overloaded definition,
both method == in class Object of type (AnyRef)Boolean
and method == in class Long of type (Long)Boolean
match argument types (Long with WinnerIdNominator)
case class Winner(id: Long with WinnerIdNominator, numbers: List
[Int])
2. How to get access to Nominator.name using reflection?
When extracting values we have json and type of target instance, in
this example classOf[Lotto]. It is not clear to me how those traits
should be reflected at runtime.
Cheers Joni
On Sep 14, 1:31?am, marius d. marius.dan...@gmail.com wrote:
On Sep 13, 3:15?pm, Joni Freeman freeman.j...@gmail.com wrote:
Hi,
That annotation is used to configure the json path when extracting
values. By default the extraction code assumes that case class
parameter names match with json field names. For instance these match:
case class Foo(bar: String, baz: Int)
{ bar: qwerty, baz: 10 }
But sometimes json field names can contain characters which are not
allowed in Scala identifiers. For example:
{ foo-bar: qwerty, baz: 10 }
Now, to able to extract this we have to somehow tell the extractor the
exact path explicitly. Currently @path annotation is used for that:
case class Foo(@path(foo-bar) bar: String, baz: Int)
I don't see how a trait can accomplish this, maybe I'm missing
something?
The reason why it is in Java is that Scala annotations are not
accessible at ?runtime.
Right but I'd also suggest removing Java code from Lift stack. The
above can be easily achieved by introducing a trait such as:
case class Foo(bar: String with Nominator, baz: Int)
Lift is a 100% Scala code with zero Java code. We also have strong
opinions in the team that we should stay away from annotations.
one option would be something like this:
Lift would have :
trait Nominator{
? def name : String
}
In user's code:
case class Foo(bar: String with MyNominator, baz: Int)
trait MyNominator extends Nominator {
?def name = foo-bar
}
Yes it is more verbose then the annotation but IMHO it is more Scala-
ish Lift-ish.
Cheers Joni
On Sep 13, 11:03?pm,
[Lift] mvn war has no love for yui compressor
Hi,
I have my js and css in my webapp directory and for a long time I had
been blissfully assuming that everything was nicely minified in my
deployed wars. So, I was very shocked to notice that although yui
compressor appears to be doing its magic during the compile stage, its
output is overwritten by mvn during the war stage. Grrr.
I believe that this is not a problem if js css are put in the
resources directory? but that seems less than ideal. I played around
a bit with the pom and got to this working solution:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
configuration
webResources
resource
directory${project.build.directory}/minimized/
directory
targetPath//targetPath
filteringfalse/filtering
/resource
/webResources
/configuration
/plugin
plugin
groupIdnet.sf.alchim/groupId
artifactIdyuicompressor-maven-plugin/artifactId
executions
execution
goals
goalcompress/goal
/goals
/execution
/executions
configuration
webappDirectory${project.build.directory}/minimized/
webappDirectory
nosuffixtrue/nosuffix
/configuration
/plugin
--~--~-~--~~~---~--~~
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: Getting Maven Offline Mode Working
Ahh, thanks Josh. It turns out I had a third version of Maven at / Applications/liftweb-1.0/apache-maven, in addition to /user/share/java/ apache-maven-2.0.9 and the 2.2.1 version I downloaded. Removing it from my PATH got me using the 2.2.1 version. Who's responsible for the OS X Lift installer? Can we update it to use the latest versions of Lift, Maven, and JavaRebel? How can I help? Peter On Sep 13, 6:21 pm, Josh Suereth joshua.suer...@gmail.com wrote: Check your PATH variable, probably pointing to the wrong maven still. You really need to get off of maven 2.0.9. The offlline mode is broken. 2.0.10 should be the minimum version you need to fix that issue. On Sun, Sep 13, 2009 at 8:33 PM, Peter Robinett pe...@bubblefoundry.comwrote: Thanks, Kevin. Dropping in the latest version didn't seem to work (mvn --version kept saying I still had 2.0.9) but switching to 1.1-M5 did. Peter On Sep 13, 4:00 pm, Kevin Wright kev.lee.wri...@googlemail.com wrote: Maven is essentially a java application, so you *should* just be able to download and run. I'm afraid I can't really give better advice for OS-X though. One other idea is to work with 1.1-M5, which should let you go offline on the older maven version - assuming you have no other snapshot dependencies. On Sun, Sep 13, 2009 at 10:51 PM, Peter Robinett pe...@bubblefoundry.comwrote: Thanks. I have version 2.0.9, which was installed by the Lift OS X installer. What is the best way to upgrade to 2.2.1? Peter On Sep 13, 12:57 pm, Kevin Wright kev.lee.wri...@googlemail.com wrote: Try updating to the latest maven, older versions have known issues with offline behaviour for snapshots. On Sun, Sep 13, 2009 at 8:55 PM, Peter Robinett pe...@bubblefoundry.com wrote: Hi all, I'm having problems running mvn -o jetty:run with my version of Lift (1.1-SNAPSHOT) because Maven thinks that net.liftweb:lift-core:jar:1.1- SNAPSHOT is missing. How do I fix that? My pom.xml is here: http://gist.github.com/186293 I've got an international plane flight in 24 hours, so I'd love to have offline mode working for then. Thanks for the help! Peter --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
