[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 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 > wrote: > > > > > 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 > > 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 > > > > 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] 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:
org.apache.maven.plugins
maven-war-plugin
${project.build.directory}/minimized
/
false
net.sf.alchim
yuicompressor-maven-plugin
compress
${project.build.directory}/minimized
true
--~--~-~--~~~---~--~~
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 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 Freeman 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])
> :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." wrote:
>
> > On Sep 13, 3:15?pm, Joni Freeman 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 Nominato
[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 Freeman 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])
: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." wrote:
> On Sep 13, 3:15?pm, Joni Freeman 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 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])
: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." wrote:
> On Sep 13, 3:15 pm, Joni Freeman 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 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 Freeman 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 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. wrote:
>
> > On Sep 13, 3:15 pm, Joni Freeman 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 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?
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 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. wrote:
>
> > On Sep 13, 3:15 pm, Joni Freeman 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 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] 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] 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] 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 > 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 everyt
[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" wrote: >> marius d. wrote: >>> I'm thinking that instead of: >>> Press me>> button> >>> We could have: >>> Press me >> 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
On Sep 13, 8:00 pm, "Charles F. Munat" wrote: > marius d. wrote: > > I'm thinking that instead of: > > > Press me > button> > > > We could have: > > > Press me > > 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
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. 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:
>
> Press me button>
>
> We could have:
>
> Press me
>
> ...
>
> .. and at the end of the page:
>
>
>
> function liftAjax(id) {
> liftAjax.lift_ajaxHandler(id + '=true',null, null, null); return
> false;
> }
> ...
>
>
>
> 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 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. 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 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
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 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
[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 wrote: > > 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 > 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 > > > 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: 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. wrote:
>
>
>
> On Sep 13, 3:15 pm, Joni Freeman 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 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: Lift deal breakers
marius d. wrote: > I'm thinking that instead of: > > Press me button> > > We could have: > > Press me 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: 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. 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:
Press me
We could have:
Press me
...
.. and at the end of the page:
function liftAjax(id) {
liftAjax.lift_ajaxHandler(id + '=true',null, null, null); return
false;
}
...
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 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. 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 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. 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 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/l
[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:
Press me
We could have:
Press me
...
.. and at the end of the page:
function liftAjax(id) {
liftAjax.lift_ajaxHandler(id + '=true',null, null, null); return
false;
}
...
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 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. 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 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 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 > 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 > > 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 > >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
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 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. 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 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
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 Wright 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 > 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 >> 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 >> > 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: Best way to write a wizard
Okay, here's what I mean.
Using chooseTemplate:
View:
...
M:
Last:
First:
...
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:
M:
Last:
First:
...
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 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 Perrett 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
> 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 Perrett 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 Suereth 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
> >>
> >>
> >>
> >>>
> >>
> >
> >
> >
> >
> > >
> >
>
> >
--~--~-~--~~~---~--~~
[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. 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 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
+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: 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 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 > 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 >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: Why isn't this a trait in lift-json?
On Sep 13, 3:15 pm, Joni Freeman 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 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
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 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 > 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: Best way to write a wizard
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 Perrett 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 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 Perrett 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 Suereth 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: 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 "bind"ing 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 Perrett 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 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 Perrett 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 Suereth 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-wiz
[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 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
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 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 Perrett 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 Suereth 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: Best way to write a wizard
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 Perrett 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 Suereth 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: 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 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] 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: 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] Re: Best way to write a wizard
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 Suereth 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: 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 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] 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: Best way to write a wizard
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 Suereth 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
On Sep 13, 11:33 am, valotas 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:
> Press me
>
> you could have something like:
> Press me
>
> and at the end of the page add the javascript:
>
> $(function() {
> $("#liftajax_{some_generated_id}").click(function()
> {the_lift_ajaxHandler_call_here()})})
>
>
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:
> Press me
>
> and then at the end of the page add:
>
> $(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
>
>
>
> 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:
>
>
> 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." 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 wrote:
>
> > > Maybe adding javascript event handlers could be delegated to something
> > > that depends on which library is being used?
>
> > > -
>
> > > Kevin Wright wrote:
>
> > > Moving the script import shouldn't be too difficult, we have the
> > >
> > > 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
> > > wrote:
>
> > > > 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
[Lift] Re: using jquery 1.3.2 and 'tabs'
David,
1. Lift includes jquery-1.3.2, just do:
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
Hope this helps.
Cheers, Indrajit
On Sep 13, 9:43 am, David 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>
>