[Lift] Re: Why the liftweb doesn't use mysql as the default database ?
I absolutely agree with the last statement. We changed from MySQL to PostgreSQL. Most of us here are Oracle DBAs, and we feel at home with PostgreSQL. We have made tests in the three platforms and we have chosen PostgreSQL. PostgreSQL gives us most of the main features of Oracle in an open source platform. Cheers, On Oct 19, 2009, at 6:18 PM, David Pollak wrote: > > > On Mon, Oct 19, 2009 at 1:10 AM, Neil.Lv wrote: > > Hi all, > > Why the liftweb doesn't use MySQL as the default database ? > > In addition to the reasons listed in this thread (most importantly, > Lift default apps "just work" with just Java and Maven installed), I > recommend against using MySQL. > > Both PostgreSQL and H2 are higher performance and PostgreSQL has far > more features. > > I have a personal bond with the MySQL folks and really wish that I > could say different, but I've also been involved with some of the > highest volume MySQL-based sites around and seen the benchmarks of > MySQL vs. PostgreSQL. It's pretty simple, if you have a choice > between the two, use PostgeSQL. > > > Thanks very much ! > > Cheers, > Neil > > > > > > -- > Lift, the simply functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Surf the harmonics > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to 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: Are we willing to make a breaking change for Joda Time?
I agree that the goal isn't to remove java.util.Date. For trivial time handling it works just fine. What I'm trying to achieve here is a way to make Joda Time be the default impl while leaving the user a choice. By using separate traits instead of different names on the same trait, we achieve a few things: 1. A consistent API for both java.util and Joda Time in terms of method names. As Naftoli pointed out, people expect naming of functions consistent with what they do and having two different "now"s on the same trait is going to look a little strange to people, I think. 2. A clean *optional* usage of Joda Time. If we put code that utilizes Joda Time directly into TimeHelpers then it's not an optional dependency. Making a separate trait means that if someone doesn't use the Joda Time trait then they don't need to have the Joda Time jar in their classpath and they never know that it's not there. 3. A relatively simple code change path to move from java.util to Joda Time by simply changing imports. Your assertion that Date is a simple wrapper for a Long timestamp is pretty accurate, but really Joda Time's DateTime is a superset of *Calendar*, not Date. Just look at what we had to do with CalendarExtension to get some simple date manipulation functions, where those same methods are already defined on DateTime. The vast majority of Joda Time's classes are immutable, and the mutators return new instances instead of modifying the current instance. TimeSpan's current handling of duration addition doesn't cope with DST, which I'm sure will show up as a bug in someone's code if it hasn't already. Having done a fair amount of java.util.Date handling and then moving to Joda Time, I find it hard to call the difference between the two APIs "marginal". In any case, I still feel that my proposal makes Joda Time available in a nicer way while leaving existing code completely untouched (by introducing a JodaHelpers trait that mirrors Helpers). Derek On Tue, Oct 20, 2009 at 9:25 PM, David Pollak wrote: > > > On Tue, Oct 20, 2009 at 6:56 PM, Naftoli Gugenheim > wrote: > >> >> I agree with this. >> My understanding is that the goal is that Lift should use Joda for its >> time functions rather than java.util. > > > This is not the goal. The goal is to make JodeTime available. There is no > reason to remove support for java.util.Date. None. > > JodaTime offers some advantages, but there's no reason, none, nada, to > *remove* support for java.util.Date. > > I'm cool with different names (not jtNow, but choose something else). > > But I view removal of support for java.util.Date as gratuitous. Sure, if > we were to make the clean-slate decision today, I'd opt for primary support > of JodaTime and secondary support for java.util.Date. But we're making a > decision based on legacy. We're not going to cut off java.util.Date just > because something marginally better (and I'm not being facetious here... at > the bottom, these are just wrappers for number of milliseconds since Jan 1, > 1970). > > >> If the Joda methods have different and longer names, then it's existing >> side by side with the java.util implementation, not replacing it. >> To many people, it is important that methods etc. should be named properly >> and aesthetically. It's not pleasant to use names like "jtNow" in your code >> when that is the method that gets used normally. Sure, if 'now' was the >> usual method and a 'jtNow' method was called in special circumstances, it's >> an understandable name. But names that are used in ordinary circumstances >> should have straightforward names. >> (Names should be concise expressions of what they represent. This aids in >> memorization and code readability.) >> Also, it will be impossible to deprecate the java.util implementation and >> have a clean API instead. If we use separate traits with the same method >> names, then we will be able to. >> >> >> - >> Derek Chen-Becker wrote: >> >> On Tue, Oct 20, 2009 at 4:59 PM, David Pollak < >> feeder.of.the.be...@gmail.com >> > wrote: >> >> > What I checked in allows you to use JodaTime just as easily (well with 2 >> > extra characters in a few method names) as java.util.Date. How is >> anything >> > more "default" than that? >> > >> >> My primary concern with this approach is that it makes changing between >> the >> two implementations something that requires a global search and replace on >> one or more method names, whereas having two different implementation >> traits >> means that generally I should be able to just change the import and the >> code >> will work. A secondary (minor) concern is that having method names reflect >> the underlying implementation details goes against my aesthetics. >> >> >> > It's an interesting difference between an OO vs. non-OO. In the >> > implementation I created, there choice of one or the other is made based >> on >> > singleton methods invoked. This allows
[Lift] Re: html not being evalutated
OK, I see why this is happening. the {exp} in the NodeSeq convert exp
to a String. So I did by creating a string and then converting it to a
NodeSeq at the end. Is there a way to do this without using and
intermediary string?
On Oct 21, 1:03 am, jack wrote:
> I have the following method display. source.body has html tags in it
> but the actual tags are showing instead of being evaluated. e.g. I'm
> seeing things like 'Hey There' instead of 'Hey There' in bold.
> This method is in a CometActor and is running when the page is
> rendered. Am I missing something obvious?
>
> def display(sources:List[Source]):NodeSeq = {
>
>
> {
> for {source <- sources} yield {source.body}
> }
>
>
>
> }
--~--~-~--~~~---~--~~
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] html not being evalutated
I have the following method display. source.body has html tags in it
but the actual tags are showing instead of being evaluated. e.g. I'm
seeing things like 'Hey There' instead of 'Hey There' in bold.
This method is in a CometActor and is running when the page is
rendered. Am I missing something obvious?
def display(sources:List[Source]):NodeSeq = {
{
for {source <- sources} yield {source.body}
}
}
--~--~-~--~~~---~--~~
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: Are we willing to make a breaking change for Joda Time?
On Tue, Oct 20, 2009 at 6:56 PM, Naftoli Gugenheim wrote: > > I agree with this. > My understanding is that the goal is that Lift should use Joda for its time > functions rather than java.util. This is not the goal. The goal is to make JodeTime available. There is no reason to remove support for java.util.Date. None. JodaTime offers some advantages, but there's no reason, none, nada, to *remove* support for java.util.Date. I'm cool with different names (not jtNow, but choose something else). But I view removal of support for java.util.Date as gratuitous. Sure, if we were to make the clean-slate decision today, I'd opt for primary support of JodaTime and secondary support for java.util.Date. But we're making a decision based on legacy. We're not going to cut off java.util.Date just because something marginally better (and I'm not being facetious here... at the bottom, these are just wrappers for number of milliseconds since Jan 1, 1970). > If the Joda methods have different and longer names, then it's existing > side by side with the java.util implementation, not replacing it. > To many people, it is important that methods etc. should be named properly > and aesthetically. It's not pleasant to use names like "jtNow" in your code > when that is the method that gets used normally. Sure, if 'now' was the > usual method and a 'jtNow' method was called in special circumstances, it's > an understandable name. But names that are used in ordinary circumstances > should have straightforward names. > (Names should be concise expressions of what they represent. This aids in > memorization and code readability.) > Also, it will be impossible to deprecate the java.util implementation and > have a clean API instead. If we use separate traits with the same method > names, then we will be able to. > > > - > Derek Chen-Becker wrote: > > On Tue, Oct 20, 2009 at 4:59 PM, David Pollak < > feeder.of.the.be...@gmail.com > > wrote: > > > What I checked in allows you to use JodaTime just as easily (well with 2 > > extra characters in a few method names) as java.util.Date. How is > anything > > more "default" than that? > > > > My primary concern with this approach is that it makes changing between the > two implementations something that requires a global search and replace on > one or more method names, whereas having two different implementation > traits > means that generally I should be able to just change the import and the > code > will work. A secondary (minor) concern is that having method names reflect > the underlying implementation details goes against my aesthetics. > > > > It's an interesting difference between an OO vs. non-OO. In the > > implementation I created, there choice of one or the other is made based > on > > singleton methods invoked. This allows mixing both in the same code > simply > > by invoking now or jtNow. > > > > I would argue that it's not a common case where you would want to use both > libraries, particularly when Joda's DateTime has an explicit toDate on it > that returns a java.util.Date. There are similar methods to return Calendar > and TimeZone instances as needed. These are simple methods to use directly, > or it's easy to create a view that handles this automatically. > > I'm unclear why this is not possible. We can add a DSL for manipulating > > JodaTime without breaking anything we have. The TimeSpan class simply > gets > > enhanced to deal with additional stuff and maybe uses JodaTime under the > > covers. > > > > The underpinning of the current DSL is the TimeSpan class. Joda Time > already > has a time interval class corresponding to TimeSpan called Duration, but > the > more proper class to use is actually Period. Period is premised not on ms > duration but rather on field deltas, which allows it to properly handle > DST. > Modifying the current DSL to work for Duration and Period via TimeSpan is > just going to end up with a lot of redundant code, when a Joda-only DSL > would be cleaner and more in line with how you would want to use Joda Time. > > > > They have that now with the implementation I did on your branch. > > > > Like I said before, I have a strong preference for the OO approach and > being > able to change impls by changing the import rather than having to change > methods all over the place. If you really feel strongly that we can't have > a > separate trait in Lift, I can just create a different artifact in my own > repo that tracks Lift and create the JodaHelpers, JodaTimeFormats and > JodaTimeHelpers traits there. > > Cheers, > > Derek > > > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@goo
[Lift] Re: css, javascript, images are all in the WEB-INF ?
On Tue, Oct 20, 2009 at 6:20 PM, Neil.Lv wrote: > > Hi all, > > I have a newbie issue about the path . > > The css, javascript, images folder are all in the WEB-INF or you > can specify the path ? > WEB-INF is where the stuff that's not going to be served by the container lives. Put images in /images, CSS in /css, etc. or whatever layout you want. > > Thanks for any suggestion! > > Cheers, > Neil > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to 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: S.uri not including query params
Then my addition to MetaMegaProtoUser of loginRedirect has a bug, because loginFirst sets it based on S.uri. Since I'm not usually around an internet connection, I won't be able to go through filing a ticket, putting a diff on Review Board, and pushing it, in any small amount of time. - David Pollak wrote: On Tue, Oct 20, 2009 at 2:48 PM, Naftoli Gugenheim wrote: > Is S.uri supposed to return the part of the URL after '?'? > No > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to 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: Are we willing to make a breaking change for Joda Time?
I agree with this. My understanding is that the goal is that Lift should use Joda for its time functions rather than java.util. If the Joda methods have different and longer names, then it's existing side by side with the java.util implementation, not replacing it. To many people, it is important that methods etc. should be named properly and aesthetically. It's not pleasant to use names like "jtNow" in your code when that is the method that gets used normally. Sure, if 'now' was the usual method and a 'jtNow' method was called in special circumstances, it's an understandable name. But names that are used in ordinary circumstances should have straightforward names. (Names should be concise expressions of what they represent. This aids in memorization and code readability.) Also, it will be impossible to deprecate the java.util implementation and have a clean API instead. If we use separate traits with the same method names, then we will be able to. - Derek Chen-Becker wrote: On Tue, Oct 20, 2009 at 4:59 PM, David Pollak wrote: > What I checked in allows you to use JodaTime just as easily (well with 2 > extra characters in a few method names) as java.util.Date. How is anything > more "default" than that? > My primary concern with this approach is that it makes changing between the two implementations something that requires a global search and replace on one or more method names, whereas having two different implementation traits means that generally I should be able to just change the import and the code will work. A secondary (minor) concern is that having method names reflect the underlying implementation details goes against my aesthetics. > It's an interesting difference between an OO vs. non-OO. In the > implementation I created, there choice of one or the other is made based on > singleton methods invoked. This allows mixing both in the same code simply > by invoking now or jtNow. > I would argue that it's not a common case where you would want to use both libraries, particularly when Joda's DateTime has an explicit toDate on it that returns a java.util.Date. There are similar methods to return Calendar and TimeZone instances as needed. These are simple methods to use directly, or it's easy to create a view that handles this automatically. I'm unclear why this is not possible. We can add a DSL for manipulating > JodaTime without breaking anything we have. The TimeSpan class simply gets > enhanced to deal with additional stuff and maybe uses JodaTime under the > covers. > The underpinning of the current DSL is the TimeSpan class. Joda Time already has a time interval class corresponding to TimeSpan called Duration, but the more proper class to use is actually Period. Period is premised not on ms duration but rather on field deltas, which allows it to properly handle DST. Modifying the current DSL to work for Duration and Period via TimeSpan is just going to end up with a lot of redundant code, when a Joda-only DSL would be cleaner and more in line with how you would want to use Joda Time. > They have that now with the implementation I did on your branch. > Like I said before, I have a strong preference for the OO approach and being able to change impls by changing the import rather than having to change methods all over the place. If you really feel strongly that we can't have a separate trait in Lift, I can just create a different artifact in my own repo that tracks Lift and create the JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits there. Cheers, Derek --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] css, javascript, images are all in the WEB-INF ?
Hi all, I have a newbie issue about the path . The css, javascript, images folder are all in the WEB-INF or you can specify the path ? Thanks for any suggestion! Cheers, Neil --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: How to disable a textfield
Thanks Tim
On Oct 20, 6:02 pm, Timothy Perrett wrote:
> Change -> to -%>
>
> Doing this preserves any element attributes, for example:
> disabled="disabled"
>
> Cheers, Tim
>
> On Oct 20, 6:30 am, sunanda wrote:
>
>
>
> > Hi,
> > I need to disable all the textfield and then want to enable the fields
> > for editing on click of a button.
> > How can i do this with the following sample code.
> > Thanks
> > Regards,
> > Sunanda.
>
> > bind("add",html,
> > "displayname"->coldef.displayname.toForm,
> > "columntype"->coldef.coltype.toForm,
> > "sourceview"->coldef.sourceview.toForm)- Hide quoted
> > text -
>
> - Show quoted text -
--~--~-~--~~~---~--~~
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: Trouble With JPA Book Example
Still getting the same issue, with
mvn -U archetype:generate \
-DarchetypeRepository=http://scala-tools.org/repo-snapshots \
-DarchetypeGroupId=net.liftweb \
-DarchetypeArtifactId=lift-archetype-jpa-basic \
-DarchetypeVersion=1.1-SNAPSHOT \
-DgroupId=com.foo.jpaweb \
-DartifactId=JPADemo \
-Dversion=1.0-SNAPSHOT
On Oct 20, 7:58 pm, David Pollak
wrote:
> For some reason the pom.xml files in the JPA archetypes referred to lift M4
> rather than SNAPSHOT. I've pushed a change. Once the build
> (http://hudson.scala-tools.org/job/Lift/1298/) is done, try re-executing
> your mvn command (make sure you do a mvn -U to pull the latest).
>
> To the committers - sorry for not going through review board on this one,
> but it was a clear problem with a clear fix (kind of like pushing a fix to a
> type-o in documentation)
>
>
>
> On Tue, Oct 20, 2009 at 4:28 PM, AndyM wrote:
>
> > I'm having trouble doing an mvn install on the JPA example from the
> > book...
>
> > > mvn archetype:generate \
> > -DarchetypeRepository=http://scala-tools.org/repo-snapshots\
> > -DarchetypeGroupId=net.liftweb \
> > -DarchetypeArtifactId=lift-archetype-jpa-basic \
> > -DarchetypeVersion=1.1-SNAPSHOT \
> > -DgroupId=com.foo.jpaweb \
> > -DartifactId=JPADemo \
> > -Dversion=1.0-SNAPSHOT
>
> > >cd JPADemo
> > >mvn install
>
> > org.apache.maven.reactor.MavenExecutionException: The POM expression: $
> > {scala.version} could not be evaluated. Reason: Expression value '$
> > {scala.version}' references itself in 'com.foo.jpaweb:JPADemo:pom:1.0-
> > SNAPSHOT'. for project com.foo.jpaweb:JPADemo at /home/amast/lift/
> > bookexample/JPADemo/pom.xml
> > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
> > [deleted for brevity]
> > at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> > Caused by: org.apache.maven.project.InvalidProjectModelException: The
> > POM expression: ${scala.version} could not be evaluated. Reason:
> > Expression value '${scala.version}' references itself in
> > 'com.foo.jpaweb:JPADemo:pom:1.0-SNAPSHOT'. for project
> > com.foo.jpaweb:JPADemo at /home/amast/lift/bookexample/JPADemo/pom.xml
> > at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal
> > (DefaultMavenProjectBuilder.java:882)
> > at
>
> > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal
> > (DefaultMavenProjectBuilder.java:506)
> > ... [deleted for brevity]
> > Caused by:
> > org.apache.maven.project.interpolation.ModelInterpolationException:
> > The POM expression: ${scala.version} could not be evaluated. Reason:
> > Expression value '${scala.version}' references itself in
> > 'com.foo.jpaweb:JPADemo:pom:1.0-SNAPSHOT'.
> > at
>
> > org.apache.maven.project.interpolation.RegexBasedModelInterpolator.interpolateInternal
> > (RegexBasedModelInterpolator.java:172)
> > ...[deleted for brevity]
>
> > Any help would be greatly appreciated.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Surf the harmonics
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Trouble With JPA Book Example
For some reason the pom.xml files in the JPA archetypes referred to lift M4
rather than SNAPSHOT. I've pushed a change. Once the build (
http://hudson.scala-tools.org/job/Lift/1298/ ) is done, try re-executing
your mvn command (make sure you do a mvn -U to pull the latest).
To the committers - sorry for not going through review board on this one,
but it was a clear problem with a clear fix (kind of like pushing a fix to a
type-o in documentation)
On Tue, Oct 20, 2009 at 4:28 PM, AndyM wrote:
>
> I'm having trouble doing an mvn install on the JPA example from the
> book...
>
> > mvn archetype:generate \
> -DarchetypeRepository=http://scala-tools.org/repo-snapshots \
> -DarchetypeGroupId=net.liftweb \
> -DarchetypeArtifactId=lift-archetype-jpa-basic \
> -DarchetypeVersion=1.1-SNAPSHOT \
> -DgroupId=com.foo.jpaweb \
> -DartifactId=JPADemo \
> -Dversion=1.0-SNAPSHOT
>
> >cd JPADemo
> >mvn install
>
> org.apache.maven.reactor.MavenExecutionException: The POM expression: $
> {scala.version} could not be evaluated. Reason: Expression value '$
> {scala.version}' references itself in 'com.foo.jpaweb:JPADemo:pom:1.0-
> SNAPSHOT'. for project com.foo.jpaweb:JPADemo at /home/amast/lift/
> bookexample/JPADemo/pom.xml
>at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
> [deleted for brevity]
>at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.project.InvalidProjectModelException: The
> POM expression: ${scala.version} could not be evaluated. Reason:
> Expression value '${scala.version}' references itself in
> 'com.foo.jpaweb:JPADemo:pom:1.0-SNAPSHOT'. for project
> com.foo.jpaweb:JPADemo at /home/amast/lift/bookexample/JPADemo/pom.xml
>at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal
> (DefaultMavenProjectBuilder.java:882)
>at
>
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal
> (DefaultMavenProjectBuilder.java:506)
>... [deleted for brevity]
> Caused by:
> org.apache.maven.project.interpolation.ModelInterpolationException:
> The POM expression: ${scala.version} could not be evaluated. Reason:
> Expression value '${scala.version}' references itself in
> 'com.foo.jpaweb:JPADemo:pom:1.0-SNAPSHOT'.
>at
>
> org.apache.maven.project.interpolation.RegexBasedModelInterpolator.interpolateInternal
> (RegexBasedModelInterpolator.java:172)
> ...[deleted for brevity]
>
>
> Any help would be greatly appreciated.
>
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to 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: Are we willing to make a breaking change for Joda Time?
Or, if you're OK with it, I could just make a lift-joda module that has the traits. That would also keep the Joda Time dependency out of the main lift modules. On Tue, Oct 20, 2009 at 5:48 PM, Derek Chen-Becker wrote: > On Tue, Oct 20, 2009 at 4:59 PM, David Pollak < > feeder.of.the.be...@gmail.com> wrote: > >> What I checked in allows you to use JodaTime just as easily (well with 2 >> extra characters in a few method names) as java.util.Date. How is anything >> more "default" than that? >> > > My primary concern with this approach is that it makes changing between the > two implementations something that requires a global search and replace on > one or more method names, whereas having two different implementation traits > means that generally I should be able to just change the import and the code > will work. A secondary (minor) concern is that having method names reflect > the underlying implementation details goes against my aesthetics. > > >> It's an interesting difference between an OO vs. non-OO. In the >> implementation I created, there choice of one or the other is made based on >> singleton methods invoked. This allows mixing both in the same code simply >> by invoking now or jtNow. >> > > I would argue that it's not a common case where you would want to use both > libraries, particularly when Joda's DateTime has an explicit toDate on it > that returns a java.util.Date. There are similar methods to return Calendar > and TimeZone instances as needed. These are simple methods to use directly, > or it's easy to create a view that handles this automatically. > > I'm unclear why this is not possible. We can add a DSL for manipulating >> JodaTime without breaking anything we have. The TimeSpan class simply gets >> enhanced to deal with additional stuff and maybe uses JodaTime under the >> covers. >> > > The underpinning of the current DSL is the TimeSpan class. Joda Time > already has a time interval class corresponding to TimeSpan called Duration, > but the more proper class to use is actually Period. Period is premised not > on ms duration but rather on field deltas, which allows it to properly > handle DST. Modifying the current DSL to work for Duration and Period via > TimeSpan is just going to end up with a lot of redundant code, when a > Joda-only DSL would be cleaner and more in line with how you would want to > use Joda Time. > > >> They have that now with the implementation I did on your branch. >> > > Like I said before, I have a strong preference for the OO approach and > being able to change impls by changing the import rather than having to > change methods all over the place. If you really feel strongly that we can't > have a separate trait in Lift, I can just create a different artifact in my > own repo that tracks Lift and create the JodaHelpers, JodaTimeFormats and > JodaTimeHelpers traits there. > > Cheers, > > Derek > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Are we willing to make a breaking change for Joda Time?
On Tue, Oct 20, 2009 at 4:59 PM, David Pollak wrote: > What I checked in allows you to use JodaTime just as easily (well with 2 > extra characters in a few method names) as java.util.Date. How is anything > more "default" than that? > My primary concern with this approach is that it makes changing between the two implementations something that requires a global search and replace on one or more method names, whereas having two different implementation traits means that generally I should be able to just change the import and the code will work. A secondary (minor) concern is that having method names reflect the underlying implementation details goes against my aesthetics. > It's an interesting difference between an OO vs. non-OO. In the > implementation I created, there choice of one or the other is made based on > singleton methods invoked. This allows mixing both in the same code simply > by invoking now or jtNow. > I would argue that it's not a common case where you would want to use both libraries, particularly when Joda's DateTime has an explicit toDate on it that returns a java.util.Date. There are similar methods to return Calendar and TimeZone instances as needed. These are simple methods to use directly, or it's easy to create a view that handles this automatically. I'm unclear why this is not possible. We can add a DSL for manipulating > JodaTime without breaking anything we have. The TimeSpan class simply gets > enhanced to deal with additional stuff and maybe uses JodaTime under the > covers. > The underpinning of the current DSL is the TimeSpan class. Joda Time already has a time interval class corresponding to TimeSpan called Duration, but the more proper class to use is actually Period. Period is premised not on ms duration but rather on field deltas, which allows it to properly handle DST. Modifying the current DSL to work for Duration and Period via TimeSpan is just going to end up with a lot of redundant code, when a Joda-only DSL would be cleaner and more in line with how you would want to use Joda Time. > They have that now with the implementation I did on your branch. > Like I said before, I have a strong preference for the OO approach and being able to change impls by changing the import rather than having to change methods all over the place. If you really feel strongly that we can't have a separate trait in Lift, I can just create a different artifact in my own repo that tracks Lift and create the JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits there. Cheers, Derek --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Trouble With JPA Book Example
I'm having trouble doing an mvn install on the JPA example from the
book...
> mvn archetype:generate \
-DarchetypeRepository=http://scala-tools.org/repo-snapshots \
-DarchetypeGroupId=net.liftweb \
-DarchetypeArtifactId=lift-archetype-jpa-basic \
-DarchetypeVersion=1.1-SNAPSHOT \
-DgroupId=com.foo.jpaweb \
-DartifactId=JPADemo \
-Dversion=1.0-SNAPSHOT
>cd JPADemo
>mvn install
org.apache.maven.reactor.MavenExecutionException: The POM expression: $
{scala.version} could not be evaluated. Reason: Expression value '$
{scala.version}' references itself in 'com.foo.jpaweb:JPADemo:pom:1.0-
SNAPSHOT'. for project com.foo.jpaweb:JPADemo at /home/amast/lift/
bookexample/JPADemo/pom.xml
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
[deleted for brevity]
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.InvalidProjectModelException: The
POM expression: ${scala.version} could not be evaluated. Reason:
Expression value '${scala.version}' references itself in
'com.foo.jpaweb:JPADemo:pom:1.0-SNAPSHOT'. for project
com.foo.jpaweb:JPADemo at /home/amast/lift/bookexample/JPADemo/pom.xml
at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal
(DefaultMavenProjectBuilder.java:882)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal
(DefaultMavenProjectBuilder.java:506)
... [deleted for brevity]
Caused by:
org.apache.maven.project.interpolation.ModelInterpolationException:
The POM expression: ${scala.version} could not be evaluated. Reason:
Expression value '${scala.version}' references itself in
'com.foo.jpaweb:JPADemo:pom:1.0-SNAPSHOT'.
at
org.apache.maven.project.interpolation.RegexBasedModelInterpolator.interpolateInternal
(RegexBasedModelInterpolator.java:172)
...[deleted for brevity]
Any help would be greatly appreciated.
--~--~-~--~~~---~--~~
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: maintaining logged in user longer outside of SessionVar
Please file a ticket. On Mon, Oct 19, 2009 at 7:04 PM, harryh wrote: > > > See ProtoExtendedSession > > It might be kind of annoying to change at this point, but "experation" > is a misspelling in this trait. > > -harryh > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to 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: Are we willing to make a breaking change for Joda Time?
On Tue, Oct 20, 2009 at 7:01 AM, Derek Chen-Becker wrote: > Here is my argument for breaking it out: > > I think that we're in agreement that the *default* impl for Lift should > eventually be Joda Time, after some period of deprecation on the old stuff. What I checked in allows you to use JodaTime just as easily (well with 2 extra characters in a few method names) as java.util.Date. How is anything more "default" than that? > I also agree with your earlier comment that it should be something that the > developer can choose. I'm sure there will be cases where people want to use > java.util instead of Joda Time because of preference or constraint (say, no > external jars). The problem is that "import Helpers._" is a very common > import, and by having TimeHelpers be part of Helpers it makes it very > difficult to do a clean separation of impls. It's an interesting difference between an OO vs. non-OO. In the implementation I created, there choice of one or the other is made based on singleton methods invoked. This allows mixing both in the same code simply by invoking now or jtNow. > My main example is the time manipulation DSL. We can't mask the implicit > defs that are already part of TimeHelpers, so it's very difficult (maybe > impossible) to define a Joda Time based DSL (which would properly handle > things like daylight savings time, etc). I'm unclear why this is not possible. We can add a DSL for manipulating JodaTime without breaking anything we have. The TimeSpan class simply gets enhanced to deal with additional stuff and maybe uses JodaTime under the covers. > By removing TimeHelpers from Helpers, it means that the user can have > absolute control over which time handling impl they're using without having > to give up all of the nice things in Helpers. They have that now with the implementation I did on your branch. > It would be a breaking change to code, but it would be pretty minor, since > the fix is just to add an import to the code that breaks. Here is my > proposal for how we change things: > > >- *version 1.1-final*: > > >1. Rename the current TimeHelpers trait to JavaTimeHelpers and add a > new TimeHelpers trait that extends JavaTimeHelpers, providing an alias. > This > means no breaking code in this release. > 2. Create a new JodaTimeHelpers that mirrors the non-deprecated > functionality of JavaTimeHelpers (there were already some deprecated > methods > on TimeHelpers that could go away). > 3. We can also copy back some of the new methods on JodaTimeHelpers > and refactor them for java.util (I'm thinking epoch and some other minor > ones). > 4. Add a JavaTimeFormatting and JodaTimeFormatting trait (currently > TimeRules in my code) that allows for custom formats and format > functions of > dates and times. The reason I want to split out the impls here, just > like > Java/JodaTimeHelpers, is so that Joda can be an optional dependency for > people who can't use it. > > >- *version 1.2-final*: > > >1. Remove the TimeHelpers trait and remove TimeHelpers from Helpers. At >this point, people would have to explicitly choose JavaTimeHelpers or >JodaTimeHelpers in their import statement to determine which impl they're >using. > > The main thing is that having TimeHelpers tied to Helpers makes it very > difficult to give the user a choice of impls, something that I feel strongly > goes against how Lift does things otherwise. > > Derek > > > On Mon, Oct 19, 2009 at 10:36 PM, David Pollak < > feeder.of.the.be...@gmail.com> wrote: > >> I have a strong preference not to break the TimeHelpers out of Helpers. >> I'm not seeing the problem with additional methods on TimeHelpers that do >> the JodaTime thing. Can you guys help me understand your point of view. >> >> >> On Mon, Oct 19, 2009 at 8:16 PM, Derek Chen-Becker > > wrote: >> >>> Oh, that was a sidetrack. I was thinking that it could help enforce the >>> common contract, but return types are different for the same method names so >>> that really wouldn't work. I really just want to try and separate them out, >>> or provide a different "Helpers" that provides JodaTime stuff under the same >>> method names. My goal is really to minimize code changes, so one or two >>> imports instead of a lot of find/replace (as simple as that may be) would be >>> preferable in my book. >>> >>> Derek >>> >>> >>> On Mon, Oct 19, 2009 at 8:53 PM, Naftoli Gugenheim >> > wrote: >>> What would be the purpose of having a common trait though? - Derek Chen-Becker wrote: That was pretty much what I was trying to communicate with my last email, just not very effectively. Derek On Mon, Oct 19, 2009 at 7:14 PM, Naftoli Gugenheim < naftoli...@gmail.com>wrote: > > Since there are anyway minor breaking changes in 1.1, maybe it's w
[Lift] Re: net.liftweb.widgets.autocomplete in version 1.1-M6
On Tue, Oct 20, 2009 at 4:15 AM, Tweek wrote:
>
> Hi,
> Previously i was working on version 1.1-M3 of lift framework and i
> used autocomplete widget by override _toForm method in my Test.scala
> file. It was something like that:
>
> object Test extends Test with KeyedMetaMapper[Long, Test] with CRUDify
> [Long,Test] {
> (...)
> }
>
> class Test extends KeyedMapper[Long, Test] {
>
> (...)
>
>object TestTable extends MappedLongForeignKey(this, TestTable) {
>def handleSubmit( string : String) = {
>
>}
>
>override def _toForm = Full( AutoComplete("", (current, limit)
> => {
>TestTable.findAll.toList.map(d => (d.name.is)) },
> handleSubmit ))
>
>}
>
> (...)
>
> }
>
> But now, after upgrade lift to version 1.1-M6, i'm getting this error:
>
> error: type mismatch;
> found : scala.xml.NodeSeq
> required: scala.xml.Elem
> override def _toForm = Full( AutoComplete("", (current,
> limit) => {
>^
> one error found.
>
>
> I can't find way to fix this problem. Could Anyone help me?
>
It looks like a defect. Please open a ticket at
http://github.com/dpp/liftweb/issues
>
> Thanks and regards
>
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to 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] Rolling out the new Lift Actors code
Folks, I've just pushed the completed Lift Actor code to the dpp_wip_actorize branch. Jonas and I coordinated on the Actor API and Akka Actors will use the same basic trait so Akka Actors could be used to power Lift's Comet. I am ready to push this code to SNAPSHOT. When I do this, there will be breaking changes to all Lift apps (basically, you'll have to import net.liftweb.base._) Does anyone have a timetable for this push? I'd like to have at least a week of solid testing before we do Milestone 7 (currently scheduled for November 4th). Please let me know your thoughts. Thanks, David -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to 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: Menu entry to perform action then redirect
Menu(Loc("logout", List("logout"), "logout", Template(() =>
{ User.logout }), ifLoggedIn)) ::
object User {
def logout = {
logUserOut
S.redirectTo("/")
}
}
On Oct 20, 5:50 pm, Naftoli Gugenheim wrote:
> Could someone give an example of a Sitemap menu entry that performs an
> action and then redirects?Thanks.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Menu entry to perform action then redirect
Loc("Feedback", List("feedback"), "Feedback", Loc.EarlyResponse(() =>
{println("I like to redirect"); S.redirectTo(S.referer openOr "/")})
On Tue, Oct 20, 2009 at 2:50 PM, Naftoli Gugenheim wrote:
> Could someone give an example of a Sitemap menu entry that performs an
> action and then redirects?Thanks.
>
>
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to 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: S.uri not including query params
On Tue, Oct 20, 2009 at 2:48 PM, Naftoli Gugenheim wrote: > Is S.uri supposed to return the part of the URL after '?'? > No > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to 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] S.uri not including query params
Is S.uri supposed to return the part of the URL after '?'? --~--~-~--~~~---~--~~ 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] Menu entry to perform action then redirect
Could someone give an example of a Sitemap menu entry that performs an action and then redirects?Thanks. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: how to use JqKeypress?
With the current function you can't. I can see a need for having the ajax
fired on key press and not on blur, so please open an issue and reference
this conversation.
Derek
On Tue, Oct 20, 2009 at 1:05 PM, harryh wrote:
>
> Yes, but then how can I distinguish back on the server whether func is
> being executed because of a blur (in which case I don't really want to
> do anything) or because of a keypress of enter (in which case I want
> to perform an action as if the go button had been pressed).
>
> -harryh
>
> On Oct 20, 11:27 am, Derek Chen-Becker wrote:
> > I think that the ajaxText already handles an "enter" key as field
> > submission. Here's the code that defines an ajaxText field:
> >
> >1. private def
> > ajaxText_*(value: String, jsFunc: Box[Call], func: AFuncHolder,
> > attrs: (String, String)*): Elem = {
> >2. val raw = (funcName: String, value:String) => JsRaw("'"
> > +funcName + "=' + encodeURIComponent(" + value + ".value)")
> >3. val key = formFuncName
> >4.
> >5. fmapFunc(func){
> >6. funcName =>
> >7. (attrs.foldLeft()(_ % _)) %
> >8. ("onkeypress" -> """liftUtils.lift_blurIfReturn(event)""") %
> >9. ("onblur" -> (jsFunc match {
> >10. case Full(f) => JsCrVar(key, JsRaw("this"
> >)) & deferCall(raw(funcName, key), f)
> >11. case _ => makeAjaxCall(raw(funcName, "this"))
> >12. })
> >13. )
> >14. }
> >15. }
> >
> > Note the "onkeypress" and "onblur" event handlers. If you need to do some
> > extra handling on the client side, you can provide the jsFunc parameter
> > which will be used to submit the ajax call.
> >
> > Derek
> >
> > On Mon, Oct 19, 2009 at 6:13 PM, harryh wrote:
> >
> > > It seems like I ought to be able to use JqKeypress so that if a user
> > > presses enter when a text input has focus an associated ajaxButton is
> > > submitted. I can't get it to work though. Help?
> >
> > > Basically I have a bunch of little form like so
> >
> > > [ text input ] [go!]
> >
> > > that I want to submit (ajax style) when the user presses enter.
> >
> > > -harryh
> >
>
--~--~-~--~~~---~--~~
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: reCaptcha integration
For a little more on Box (and Option), see
http://blog.lostlake.org/index.php?/archives/50-The-Scala-Option-class-and-how-lift-uses-it.html
On Tue, Oct 20, 2009 at 9:49 AM, CodeSlave9000 wrote:
>
> replying to myself a bit here - starting to figure some of this out:
>
> Turns out it doesn't submit the values in the form, but rather as
> parameters to the submission. I see I can get at those through
> S.param("recaptcha_challenge_field"), etc. This returns a Box
> (Full), which I now need to figure out... I suspect I need to do some
> kind of matching on it...
>
> On Oct 20, 12:09 pm, CodeSlave9000 wrote:
> > Hi - I think I'm following the rules in integrating reCaptcha into a
> > page, but I'm not seeing anything in the hidden fields when the form
> > is submitted. Am I making some kind of assumption I shouldn't be? I'm
> > rather new to Lift (and web development), so something on the simple
> > example side would probably be best understood.
> >
> > Here's some stuff I have:
> > (in html form)
> >
> >
> >
> >
> > https://api-secure.recaptcha.net/noscript?k= > here>" height="300" width="500" frameborder="0">
> > rows="3" cols="40">
> >
> >
> >
> >
> >
> > And in my snippet, the captcha is bound to:
> > "captcha" -> SHtml.text(model.captcha.value, model.captcha.value = _,
> > "type" -> "hidden", "name" -> "recaptcha_response_field"),
> >
> > model.captcha.value is always empty after form submission. Nothing
> > fancy here - just a regular form.
> > Thanks,
> > Chris
>
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to 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: reCaptcha integration
S.param("recaptcha_challenge_field") match { case Full(value) => // work
with the value of 'value'
case _ => // deal with the fact that there's no result.
}
On Tue, Oct 20, 2009 at 12:49 PM, CodeSlave9000 wrote:
>
> replying to myself a bit here - starting to figure some of this out:
>
> Turns out it doesn't submit the values in the form, but rather as
> parameters to the submission. I see I can get at those through
> S.param("recaptcha_challenge_field"), etc. This returns a Box
> (Full), which I now need to figure out... I suspect I need to do some
> kind of matching on it...
>
> On Oct 20, 12:09 pm, CodeSlave9000 wrote:
> > Hi - I think I'm following the rules in integrating reCaptcha into a
> > page, but I'm not seeing anything in the hidden fields when the form
> > is submitted. Am I making some kind of assumption I shouldn't be? I'm
> > rather new to Lift (and web development), so something on the simple
> > example side would probably be best understood.
> >
> > Here's some stuff I have:
> > (in html form)
> >
> >
> >
> >
> > https://api-secure.recaptcha.net/noscript?k= > here>" height="300" width="500" frameborder="0">
> > rows="3" cols="40">
> >
> >
> >
> >
> >
> > And in my snippet, the captcha is bound to:
> > "captcha" -> SHtml.text(model.captcha.value, model.captcha.value = _,
> > "type" -> "hidden", "name" -> "recaptcha_response_field"),
> >
> > model.captcha.value is always empty after form submission. Nothing
> > fancy here - just a regular form.
> > Thanks,
> > Chris
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: how to use JqKeypress?
Yes, but then how can I distinguish back on the server whether func is
being executed because of a blur (in which case I don't really want to
do anything) or because of a keypress of enter (in which case I want
to perform an action as if the go button had been pressed).
-harryh
On Oct 20, 11:27 am, Derek Chen-Becker wrote:
> I think that the ajaxText already handles an "enter" key as field
> submission. Here's the code that defines an ajaxText field:
>
> 1. private def
> ajaxText_*(value: String, jsFunc: Box[Call], func: AFuncHolder,
> attrs: (String, String)*): Elem = {
> 2. val raw = (funcName: String, value:String) => JsRaw("'"
> +funcName + "=' + encodeURIComponent(" + value + ".value)")
> 3. val key = formFuncName
> 4.
> 5. fmapFunc(func){
> 6. funcName =>
> 7. (attrs.foldLeft()(_ % _)) %
> 8. ("onkeypress" -> """liftUtils.lift_blurIfReturn(event)""") %
> 9. ("onblur" -> (jsFunc match {
> 10. case Full(f) => JsCrVar(key, JsRaw("this"
> )) & deferCall(raw(funcName, key), f)
> 11. case _ => makeAjaxCall(raw(funcName, "this"))
> 12. })
> 13. )
> 14. }
> 15. }
>
> Note the "onkeypress" and "onblur" event handlers. If you need to do some
> extra handling on the client side, you can provide the jsFunc parameter
> which will be used to submit the ajax call.
>
> Derek
>
> On Mon, Oct 19, 2009 at 6:13 PM, harryh wrote:
>
> > It seems like I ought to be able to use JqKeypress so that if a user
> > presses enter when a text input has focus an associated ajaxButton is
> > submitted. I can't get it to work though. Help?
>
> > Basically I have a bunch of little form like so
>
> > [ text input ] [go!]
>
> > that I want to submit (ajax style) when the user presses enter.
>
> > -harryh
--~--~-~--~~~---~--~~
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: net.liftweb.widgets.autocomplete in version 1.1-M6
Does it help to change map to flatMap?
On Tue, Oct 20, 2009 at 7:15 AM, Tweek wrote:
>
> Hi,
> Previously i was working on version 1.1-M3 of lift framework and i
> used autocomplete widget by override _toForm method in my Test.scala
> file. It was something like that:
>
> object Test extends Test with KeyedMetaMapper[Long, Test] with CRUDify
> [Long,Test] {
> (...)
> }
>
> class Test extends KeyedMapper[Long, Test] {
>
> (...)
>
>object TestTable extends MappedLongForeignKey(this, TestTable) {
>def handleSubmit( string : String) = {
>
>}
>
>override def _toForm = Full( AutoComplete("", (current, limit)
> => {
>TestTable.findAll.toList.map(d => (d.name.is)) },
> handleSubmit ))
>
>}
>
> (...)
>
> }
>
> But now, after upgrade lift to version 1.1-M6, i'm getting this error:
>
> error: type mismatch;
> found : scala.xml.NodeSeq
> required: scala.xml.Elem
> override def _toForm = Full( AutoComplete("", (current,
> limit) => {
>^
> one error found.
>
>
> I can't find way to fix this problem. Could Anyone help me?
>
> Thanks and regards
>
> >
>
--~--~-~--~~~---~--~~
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: javascript with an ajaxbutton
I was hoping to see something minimalistic and isolated so I can
quickly try it out.
I'm not sure what you do with redirect("/workflow/claims") but from
Ajax function you should probably use JsCmd.RedirectTo ..
Hopefully I'll have some time this weekend to play with tinyMCE
Br's,
Marius
On Oct 19, 10:57 pm, caw1461 wrote:
> edit.html:
>
>
>
> tinyMCE.init({
> // General options
> mode : "textareas",
> theme : "advanced",
> plugins :
> "spellchecker,pagebreak,save,advhr,advimage,advlink,iespell,inlinepopups,insertdatetime,preview,media,searchreplace,print,contextmenu,paste,directionality,noneditable,visualchars,nonbreaking,xhtmlxtras,template",
> theme_advanced_buttons1 :
> "styleselect,formatselect,fontselect,fontsizeselect,|,bold,italic,underline,strikethrough,|,justifyleft,justifycenter,justifyright,justifyfull,|,
> hr, bullist,numlist, preview, code",
> theme_advanced_buttons2 : "",
> theme_advanced_buttons3 : "",
> theme_advanced_buttons4 : "",
>
> submit_patch : false,
>
> theme_advanced_resizing : true
> });
>
> // The save function that actually works.
>
> $.saveFunc = function() { tinyMCE.activeEditor.save() };
>
> function saveT () {
> console.log("javascript console 1")
> tinyMCE.activeEditor.save()
> console.log("javascript console 2")
> };
>
> $('#fixed').click(function(e){
> tinyMCE.activeEditor.save()
> });
>
>
>
>
>
>
> title="Save, only save the html, doesn't mark the claim ready for
> publishging.">Save
>
>
>
>
>
> //*//
>
> Workflow.scala:
>
> SHtml.ajaxForm(
> bind("editor", xhtml,
>
> "text" -> SHtml.textarea(originalOrEditedFileAsString
> (selectedClaimWorkQueue.open_!.fileName),
> s => {
> println(s)
> saveClaimHtmlToDB(s)
> saveClaimHtml(s,
> selectedClaimWorkQueue.open_!.fileName)
> S.notice("Submitted.")
> redirect("/workflow/claims")
> } , ("style", "height: 500px; width:97%"), ("id",
> "mceForm")),
>
> "save" -> SHtml.ajaxButton(
> "Save",
> {() =>
> Log.info("Got a 'save' AJAX call")
> saveClaimStatus("EDITED")
> S.notice("Saved.")
> redirect("/workflow/claims")
> }, ("type", "submit"),("class", "ui-state-default "),
> ("title", "Save, only save the html, does not mark the claim ready for
> publishging."), ("id", "fixed")),
> "save1" -> SHtml.ajaxButton(
>
> "Fixed",
> { () => {
> println("Fixed scala/lift.");
> saveClaimStatus("FIXED");
> JsRaw("$.saveFunc();").cmd);
> }
> }, ("class", "ui-state-default "), ("title", "Save and
> marks the claim ready for publishing."), ("id", "fixed")),
> "save2" -> SHtml.ajaxButton(
> "yes", () => {JsRaw("$.saveFunc();").cmd })))
>
> }
>
> I'm already importing both of those so that isn't the problem. If I
> put a % ("onclick" -> "saveT()") on the button, it saves the way I
> want it to, but it does not do any of the println or saveClaimStatus
> calls. I just want it to do both.
>
> On Oct 19, 3:43 pm, Marius wrote:
>
> > I think with an
>
> > import net.liftweb.http.js._
> > import JsCmds._
>
> > the compile problem should go away as there is an implicit defined
> > there. But this is not important.
>
> > Can you send a minimalistic code example that reflects the
> > problem? ... including the template and Scala code.
>
> > Br's,
> > Marius
>
> > On Oct 19, 9:48 pm, caw1461 wrote:
>
> > > My saveClaimSatus("") function saves the passed value to the
> > > database.
> > > Firebug is not giving me any errors and prints the line to the
> > > console.
>
> > > The order in which the two updates happen is important because I need
> > > the status updated before the form is saved.
>
> > > I am using two different versions of saving to keep a temporary "save"
> > > and then a finalized "For Publish" version.
>
> > > so I need both of them to save the form, which i was trying to use the
> > > saveFunc to do.
>
> > > and removing the .cmd seems to give a syntax errors:
>
> > > E:\patentTracker3\prospective_claims_ver_br\patentTrackerUi\src\main
> > > \scala\com\trlr\binpr\snippet\Workflow.scala:473: error: overloaded
> > > method value ajaxButton with alternatives (String,() =>
> > > net.liftweb.http.js.JsCmd,(String, String)*)scala.xml.Elem
> > > (scala.xml.NodeSeq,() => net.liftweb.http.js.JsCmd,(String, String)*)
> > > scala.xml.Elem cannot be applied to (java.lang.String,() =>
> > > net.liftweb.http.js.JE.JsRaw,(java.lang.String, java.lang.String),
> > > (java.lang.String, java.lang.String
[Lift] Re: Including the class name in the JSON field
Hi,
Yes I'll put these to Review Board soon. I just add some
documentation, rerun serialization benchmark and do a little bit
testing.
Unless someone wants to discuss details/alternatives/etc more...
Cheers Joni
On 20 loka, 18:22, Derek Chen-Becker wrote:
> Are you putting these changes in Review Board, or is this still experimental
> work?
>
> Derek
>
> On Mon, Oct 19, 2009 at 9:02 AM, Joni Freeman wrote:
>
>
>
> > Added a way to change how 'type hints' are processed. The default is
> > NoTypeHints which will never output 'jsonClass' field. Then there's
> > ShortTypeHints and FullTypeHints.
>
> > implicit val formats = Serialization.formats(ShortTypeHints(classOf
> > [Fish] :: classOf[Dog] :: Nil))
>
> > -> { "jsonClass":"Fish", ... }
>
> > implicit val formats = Serialization.formats(FullTypeHints(classOf
> > [Animal] :: Nil))
>
> > -> { "jsonClass":"com.example.Fish", ... }
>
> > TypeHints trait can be used to reduce couplings (as suggested by
> > Steve).
>
> > Cheers Joni
>
> > On 18 loka, 23:46, Joni Freeman wrote:
> > > There's now some support to deserialize parameterized types in that
> > > experimental branch. For instance, these all work:
>
> > > implicit val formats = Serialization.formats(TypeHints(classOf
> > > [Animal] :: Nil))
>
> > > case class Animals(animals: List[Animal])
> > > trait Animal
> > > case class Dog(name: String) extends Animal
> > > case class Fish(weight: Double) extends Animal
>
> > > case class Objs(objects: List[Obj[_]])
> > > case class Obj[A](a: A)
>
> > > val animals = Animals(Dog("pluto") :: Fish(1.2) :: Dog("devil") ::
> > > Nil)
> > > val ser = swrite(animals)
> > > read[Animals](ser) mustEqual animals
>
> > > val objs = Objs(Obj(Fish(1.2)) :: Obj(Dog("pluto")) :: Nil)
> > > val ser = swrite(objs)
> > > read[Objs](ser) mustEqual objs
>
> > > val t: (Animal, Animal) = (Fish(1.5), Dog("pluto"))
> > > val ser = swrite(t)
> > > read[(Animal, Animal)](ser) mustEqual t
>
> > > The first line (implicit val formats ...) configures the serialization
> > > to output type hint (jsonClass field) for all instances of class
> > > Animal. This is required since above examples use Animal's in
> > > polymorphic way. Comments?
>
> > > Cheers Joni
>
> > > On 18 loka, 01:27, David Pollak wrote:
>
> > > > On Sat, Oct 17, 2009 at 7:54 AM, Joni Freeman > >wrote:
>
> > > > > I've been thinking this feature today a bit too. Marius raises an
> > > > > important point. Adding type information and more complex
> > > > > serialization scheme will introduce couplings, making it for instance
> > > > > more difficult to deserializeJSONusing a different language or
> > > > > toolkit. On a positive side, we might get support for other
> > > > > parameterized types too (tuples for instance).
>
> > > > > I pushed an experimental branch (joni_issue_108) which contains
> > > > > serialization part of this feature (the easy part really). It adds
> > > > > 'jsonClass' field to objects.
>
> > > > > case class Animals(animals: List[Animal])
> > > > > trait Animal
> > > > > case class Dog(name: String) extends Animal
> > > > > case class Fish(weight: Double) extends Animal
>
> > > > > scala> write(Animals(Dog("pluto") :: Fish(1.2) :: Dog("devil") ::
> > > > > Nil))
> > > > > res0: String = {"jsonClass":"Animals","animals":
>
> > [{"jsonClass":"Dog","name":"pluto"},{"jsonClass":"Fish","weight":1.2},
> > > > > {"jsonClass":"Dog","name":"devil"}]}
>
> > > > > Possible actions:
>
> > > > > * Do not support parameterized types (status quo)
>
> > > > > + Simple scheme, easy to serialize in language agnostic way
> > > > > - Limited
>
> > > > I like this option. I'm not looking for a full Java serialization
> > style
> > > > solution. But having hints as to the type of the particularJSONobject
> > > > would be helpful. Being able to register a "jsonClass" -> Scala class
> > > > deserializer makes sense. Being able to specify a Scala class -> class
> > name
> > > > is a good thing (with the default being the actual class name without
> > the
> > > > package).
>
> > > > > * Add full type information when serializing/deserializing
>
> > > > > + Opens possibility to deserialize polymorphic types
> > > > > + Deserialization can be done without any explicit type information
> > > > > (read(...) vs. read[ExpectedType](...))
> > > > > - Introduces couplings
> > > > > - This is still not a generic serialization solution, there's still
> > > > > a lot of Scala classes which can't be deserialized
>
> > > > > * Support both schemes
>
> > > > > + Moar choice
> > > > > - Choice it not necessarily a good thing (adds complexity etc.)
>
> > > > > Cheers Joni
>
> > > > > On 17 loka, 11:40, Marius wrote:
> > > > > > Hmmm ... I wonder if heterogeneous lists should be supported. I
> > also
> > > > > > wonder if type knowledge inJSONis a good thing to do as it seems to
> > > > > > me that we're bringing knowledge from another domain creating
> > > > > > couplings. I'm not sure i
[Lift] Re: get warnings for every request
Here's the link to my previous report -- I did some code review when looking at it last time, in case it's helpful for anyone. http://groups.google.com/group/liftweb/browse_thread/thread/c40316267412460b/16c405be378566a0 -Ross On Oct 20, 2009, at 1:13 PM, Marius wrote: > > Yup please file a ticket. I think Derek worked on this a while ago. > Derek, please correct me if I'm wrong > > Br's, > Marius > > On Oct 20, 5:16 pm, Ross Mellgren wrote: >> I encountered these and sent a message to the list last week or so. I >> didn't hear anything back, maybe the best route is to file an issue? >> >> http://github.com/dpp/liftweb/issues >> >> -Ross >> >> On Oct 20, 2009, at 5:30 AM, night_stalker wrote: >> >> >> >>> Hi all. >>> When using , the result page is fine as I wished, >>> yet these warnings run into the log for every request: >> >>> WARN - Unused binding values for : content, main >>> WARN - Unused binding values for : sidebar, main >>> WARN - Unused binding values for : sidebar >> >>> Am I missing something, or, can I disable these warnings? >>> The lift version is 1.1-M6, template code are like below: >> >>> >>> templates-hidden/someLayout.html >> >>> ...begin stuff >>> >>> ...between stuff >>> >>> ...end stuff >> >>> >>> somePage.html >> >>> >>> >>>...sidebar stuff >>> >>> >>>...content stuff >>> >>> > > --~--~-~--~~~---~--~~ 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: get warnings for every request
Yup please file a ticket. I think Derek worked on this a while ago. Derek, please correct me if I'm wrong Br's, Marius On Oct 20, 5:16 pm, Ross Mellgren wrote: > I encountered these and sent a message to the list last week or so. I > didn't hear anything back, maybe the best route is to file an issue? > > http://github.com/dpp/liftweb/issues > > -Ross > > On Oct 20, 2009, at 5:30 AM, night_stalker wrote: > > > > > Hi all. > > When using , the result page is fine as I wished, > > yet these warnings run into the log for every request: > > > WARN - Unused binding values for : content, main > > WARN - Unused binding values for : sidebar, main > > WARN - Unused binding values for : sidebar > > > Am I missing something, or, can I disable these warnings? > > The lift version is 1.1-M6, template code are like below: > > > > > templates-hidden/someLayout.html > > > ...begin stuff > > > > ...between stuff > > > > ...end stuff > > > > > somePage.html > > > > > > > ...sidebar stuff > > > > > > ...content stuff > > > > --~--~-~--~~~---~--~~ 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: reCaptcha integration
replying to myself a bit here - starting to figure some of this out:
Turns out it doesn't submit the values in the form, but rather as
parameters to the submission. I see I can get at those through
S.param("recaptcha_challenge_field"), etc. This returns a Box
(Full), which I now need to figure out... I suspect I need to do some
kind of matching on it...
On Oct 20, 12:09 pm, CodeSlave9000 wrote:
> Hi - I think I'm following the rules in integrating reCaptcha into a
> page, but I'm not seeing anything in the hidden fields when the form
> is submitted. Am I making some kind of assumption I shouldn't be? I'm
> rather new to Lift (and web development), so something on the simple
> example side would probably be best understood.
>
> Here's some stuff I have:
> (in html form)
>
>
>
>
> src="https://api-secure.recaptcha.net/noscript?k= here>" height="300" width="500" frameborder="0">
> cols="40">
>
>
>
>
>
> And in my snippet, the captcha is bound to:
> "captcha" -> SHtml.text(model.captcha.value, model.captcha.value = _,
> "type" -> "hidden", "name" -> "recaptcha_response_field"),
>
> model.captcha.value is always empty after form submission. Nothing
> fancy here - just a regular form.
> Thanks,
> Chris
--~--~-~--~~~---~--~~
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] reCaptcha integration
Hi - I think I'm following the rules in integrating reCaptcha into a page, but I'm not seeing anything in the hidden fields when the form is submitted. Am I making some kind of assumption I shouldn't be? I'm rather new to Lift (and web development), so something on the simple example side would probably be best understood. Here's some stuff I have: (in html form) https://api-secure.recaptcha.net/noscript?k=" height="300" width="500" frameborder="0"> And in my snippet, the captcha is bound to: "captcha" -> SHtml.text(model.captcha.value, model.captcha.value = _, "type" -> "hidden", "name" -> "recaptcha_response_field"), model.captcha.value is always empty after form submission. Nothing fancy here - just a regular form. Thanks, Chris --~--~-~--~~~---~--~~ 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: Setting Table Border
Get firebug and look at the CSS hierarchy for the element. That should
locate where it's being overridden pretty quickly.
Derek
On Mon, Oct 19, 2009 at 9:53 PM, sunanda wrote:
>
> Thats what I wonder. It should work. When I refer to a css file with
> the border setting it works,
> but not with the setting from the snippet. I need to figure it out.
> Thanks for your reply.
> Sunanda.
>
> On Oct 20, 2:35 pm, Ross Mellgren wrote:
> > That looks right to me -- it should show a border with a default
> > stylesheet. When I throw that ... into a HTML file by
> > itself, I get a border.
> >
> > -Ross
> >
> > On Oct 19, 2009, at 8:47 PM, sunanda wrote:
> >
> >
> >
> >
> >
> > > Hi,
> > > I need to display the table with border.
> > > Following is the sample code.
> > > But it is not displaying the border.Is this the correct way of setting
> > > the border.
> >
> > > Sunanda
> >
> > > def displayColDef(selectedname:String):NodeSeq={
> >
> > >val coldef = getColDef(selectedname)
> > >
> > >
> > >Display Name
> > > {coldef.displayname}
> > >
> > >
> > > Column Type
> > >{coldef.coltype}
> > >
> > >
> > > }- Hide quoted text -
> >
> > - Show quoted text -
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: how to use JqKeypress?
I think that the ajaxText already handles an "enter" key as field
submission. Here's the code that defines an ajaxText field:
1. private def
ajaxText_*(value: String, jsFunc: Box[Call], func: AFuncHolder,
attrs: (String, String)*): Elem = {
2. val raw = (funcName: String, value:String) => JsRaw("'"
+funcName + "=' + encodeURIComponent(" + value + ".value)")
3. val key = formFuncName
4.
5. fmapFunc(func){
6. funcName =>
7. (attrs.foldLeft()(_ % _)) %
8. ("onkeypress" -> """liftUtils.lift_blurIfReturn(event)""") %
9. ("onblur" -> (jsFunc match {
10. case Full(f) => JsCrVar(key, JsRaw("this"
)) & deferCall(raw(funcName, key), f)
11. case _ => makeAjaxCall(raw(funcName, "this"))
12. })
13. )
14. }
15. }
Note the "onkeypress" and "onblur" event handlers. If you need to do some
extra handling on the client side, you can provide the jsFunc parameter
which will be used to submit the ajax call.
Derek
On Mon, Oct 19, 2009 at 6:13 PM, harryh wrote:
>
> It seems like I ought to be able to use JqKeypress so that if a user
> presses enter when a text input has focus an associated ajaxButton is
> submitted. I can't get it to work though. Help?
>
> Basically I have a bunch of little form like so
>
> [ text input ] [go!]
>
> that I want to submit (ajax style) when the user presses enter.
>
> -harryh
>
> >
>
--~--~-~--~~~---~--~~
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: Including the class name in the JSON field
Are you putting these changes in Review Board, or is this still experimental
work?
Derek
On Mon, Oct 19, 2009 at 9:02 AM, Joni Freeman wrote:
>
> Added a way to change how 'type hints' are processed. The default is
> NoTypeHints which will never output 'jsonClass' field. Then there's
> ShortTypeHints and FullTypeHints.
>
> implicit val formats = Serialization.formats(ShortTypeHints(classOf
> [Fish] :: classOf[Dog] :: Nil))
>
> -> { "jsonClass":"Fish", ... }
>
> implicit val formats = Serialization.formats(FullTypeHints(classOf
> [Animal] :: Nil))
>
> -> { "jsonClass":"com.example.Fish", ... }
>
> TypeHints trait can be used to reduce couplings (as suggested by
> Steve).
>
> Cheers Joni
>
> On 18 loka, 23:46, Joni Freeman wrote:
> > There's now some support to deserialize parameterized types in that
> > experimental branch. For instance, these all work:
> >
> > implicit val formats = Serialization.formats(TypeHints(classOf
> > [Animal] :: Nil))
> >
> > case class Animals(animals: List[Animal])
> > trait Animal
> > case class Dog(name: String) extends Animal
> > case class Fish(weight: Double) extends Animal
> >
> > case class Objs(objects: List[Obj[_]])
> > case class Obj[A](a: A)
> >
> > val animals = Animals(Dog("pluto") :: Fish(1.2) :: Dog("devil") ::
> > Nil)
> > val ser = swrite(animals)
> > read[Animals](ser) mustEqual animals
> >
> > val objs = Objs(Obj(Fish(1.2)) :: Obj(Dog("pluto")) :: Nil)
> > val ser = swrite(objs)
> > read[Objs](ser) mustEqual objs
> >
> > val t: (Animal, Animal) = (Fish(1.5), Dog("pluto"))
> > val ser = swrite(t)
> > read[(Animal, Animal)](ser) mustEqual t
> >
> > The first line (implicit val formats ...) configures the serialization
> > to output type hint (jsonClass field) for all instances of class
> > Animal. This is required since above examples use Animal's in
> > polymorphic way. Comments?
> >
> > Cheers Joni
> >
> > On 18 loka, 01:27, David Pollak wrote:
> >
> > > On Sat, Oct 17, 2009 at 7:54 AM, Joni Freeman >wrote:
> >
> > > > I've been thinking this feature today a bit too. Marius raises an
> > > > important point. Adding type information and more complex
> > > > serialization scheme will introduce couplings, making it for instance
> > > > more difficult to deserializeJSONusing a different language or
> > > > toolkit. On a positive side, we might get support for other
> > > > parameterized types too (tuples for instance).
> >
> > > > I pushed an experimental branch (joni_issue_108) which contains
> > > > serialization part of this feature (the easy part really). It adds
> > > > 'jsonClass' field to objects.
> >
> > > > case class Animals(animals: List[Animal])
> > > > trait Animal
> > > > case class Dog(name: String) extends Animal
> > > > case class Fish(weight: Double) extends Animal
> >
> > > > scala> write(Animals(Dog("pluto") :: Fish(1.2) :: Dog("devil") ::
> > > > Nil))
> > > > res0: String = {"jsonClass":"Animals","animals":
> > > >
> [{"jsonClass":"Dog","name":"pluto"},{"jsonClass":"Fish","weight":1.2},
> > > > {"jsonClass":"Dog","name":"devil"}]}
> >
> > > > Possible actions:
> >
> > > > * Do not support parameterized types (status quo)
> >
> > > > + Simple scheme, easy to serialize in language agnostic way
> > > > - Limited
> >
> > > I like this option. I'm not looking for a full Java serialization
> style
> > > solution. But having hints as to the type of the particularJSONobject
> > > would be helpful. Being able to register a "jsonClass" -> Scala class
> > > deserializer makes sense. Being able to specify a Scala class -> class
> name
> > > is a good thing (with the default being the actual class name without
> the
> > > package).
> >
> > > > * Add full type information when serializing/deserializing
> >
> > > > + Opens possibility to deserialize polymorphic types
> > > > + Deserialization can be done without any explicit type information
> > > > (read(...) vs. read[ExpectedType](...))
> > > > - Introduces couplings
> > > > - This is still not a generic serialization solution, there's still
> > > > a lot of Scala classes which can't be deserialized
> >
> > > > * Support both schemes
> >
> > > > + Moar choice
> > > > - Choice it not necessarily a good thing (adds complexity etc.)
> >
> > > > Cheers Joni
> >
> > > > On 17 loka, 11:40, Marius wrote:
> > > > > Hmmm ... I wonder if heterogeneous lists should be supported. I
> also
> > > > > wonder if type knowledge inJSONis a good thing to do as it seems to
> > > > > me that we're bringing knowledge from another domain creating
> > > > > couplings. I'm not sure if there is a different way to solve this
> ...
> > > > > it just doesn't feel completely right to me ... but this doesn't
> > > > > necessarily mean it is not right :)
> >
> > > > > Br's,
> > > > > Marius
> >
> > > > > On Oct 15, 1:47 am, David Pollak
> > > > > wrote:
> >
> > > > > > Folks,
> > > > > > What are thoughts on including (perhaps optionally) the name of
> the
> > > > case
> > > > >
[Lift] Re: scalajpa - wrong database?
Another note is that ScalaJPA provides a pretty thin wrapper on a JPA persistence unit. Each persistence unit represents *one* database, so you actually need more than one persistence unit to have connections to two databases. I recently added support in 1.2-SNAPSHOT so that you can provide a property map to LocalEMF to allow you to use the same unit with different database connections, but if you're using JNDI that won't work. If you're still having the issue, could you post some code that shows where it's failing? Thanks, Derek On Tue, Oct 20, 2009 at 6:37 AM, Jean-Luc wrote: > Which liftweb version are you using ? > I've signaled a bug a few month ago, it was very very quickly fixed (thank > you again Derek for your reactivity !). My jpa apps are in production and I > have no such issue remaining, scalajpa looks like to be very stable. > > Once, I wrongly specified a wrong "persistence-unit/@name" value in test > mode, and it caused the same symptoms. Have you verified that your LocalEMF > configuration suits your META-INF/persistence.xml file ? > > Maybe you want to copy / paste your source code for a quick review ? > > > Jean-Luc > > 2009/10/19 TSP > >> >> I'm using scalajpa and have just downloaded source from github >> My application has 2 databases and my unit tests are creating tables >> for the second database in the first. >> This was a reported issue back around June I think, but the posts seem >> to imply it was fixed. >> Was it not? >> Thanks >> Tim >> >> > > > -- > Jean-Luc Canela > jlcane...@gmail.com > > > > > --~--~-~--~~~---~--~~ 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: get warnings for every request
I encountered these and sent a message to the list last week or so. I didn't hear anything back, maybe the best route is to file an issue? http://github.com/dpp/liftweb/issues -Ross On Oct 20, 2009, at 5:30 AM, night_stalker wrote: > > Hi all. > When using , the result page is fine as I wished, > yet these warnings run into the log for every request: > > WARN - Unused binding values for : content, main > WARN - Unused binding values for : sidebar, main > WARN - Unused binding values for : sidebar > > Am I missing something, or, can I disable these warnings? > The lift version is 1.1-M6, template code are like below: > > > templates-hidden/someLayout.html > > ...begin stuff > > ...between stuff > > ...end stuff > > > somePage.html > > > >...sidebar stuff > > >...content stuff > > > > > --~--~-~--~~~---~--~~ 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: Are we willing to make a breaking change for Joda Time?
s/version 1.2-final/some future version/ On Tue, Oct 20, 2009 at 8:01 AM, Derek Chen-Becker wrote: > Here is my argument for breaking it out: > > I think that we're in agreement that the *default* impl for Lift should > eventually be Joda Time, after some period of deprecation on the old stuff. > I also agree with your earlier comment that it should be something that the > developer can choose. I'm sure there will be cases where people want to use > java.util instead of Joda Time because of preference or constraint (say, no > external jars). The problem is that "import Helpers._" is a very common > import, and by having TimeHelpers be part of Helpers it makes it very > difficult to do a clean separation of impls. My main example is the time > manipulation DSL. We can't mask the implicit defs that are already part of > TimeHelpers, so it's very difficult (maybe impossible) to define a Joda Time > based DSL (which would properly handle things like daylight savings time, > etc). By removing TimeHelpers from Helpers, it means that the user can have > absolute control over which time handling impl they're using without having > to give up all of the nice things in Helpers. It would be a breaking change > to code, but it would be pretty minor, since the fix is just to add an > import to the code that breaks. Here is my proposal for how we change > things: > > >- *version 1.1-final*: > > >1. Rename the current TimeHelpers trait to JavaTimeHelpers and add a > new TimeHelpers trait that extends JavaTimeHelpers, providing an alias. > This > means no breaking code in this release. > 2. Create a new JodaTimeHelpers that mirrors the non-deprecated > functionality of JavaTimeHelpers (there were already some deprecated > methods > on TimeHelpers that could go away). > 3. We can also copy back some of the new methods on JodaTimeHelpers > and refactor them for java.util (I'm thinking epoch and some other minor > ones). > 4. Add a JavaTimeFormatting and JodaTimeFormatting trait (currently > TimeRules in my code) that allows for custom formats and format > functions of > dates and times. The reason I want to split out the impls here, just > like > Java/JodaTimeHelpers, is so that Joda can be an optional dependency for > people who can't use it. > > >- *version 1.2-final*: > > >1. Remove the TimeHelpers trait and remove TimeHelpers from Helpers. At >this point, people would have to explicitly choose JavaTimeHelpers or >JodaTimeHelpers in their import statement to determine which impl they're >using. > > The main thing is that having TimeHelpers tied to Helpers makes it very > difficult to give the user a choice of impls, something that I feel strongly > goes against how Lift does things otherwise. > > Derek > > > On Mon, Oct 19, 2009 at 10:36 PM, David Pollak < > feeder.of.the.be...@gmail.com> wrote: > >> I have a strong preference not to break the TimeHelpers out of Helpers. >> I'm not seeing the problem with additional methods on TimeHelpers that do >> the JodaTime thing. Can you guys help me understand your point of view. >> >> >> On Mon, Oct 19, 2009 at 8:16 PM, Derek Chen-Becker > > wrote: >> >>> Oh, that was a sidetrack. I was thinking that it could help enforce the >>> common contract, but return types are different for the same method names so >>> that really wouldn't work. I really just want to try and separate them out, >>> or provide a different "Helpers" that provides JodaTime stuff under the same >>> method names. My goal is really to minimize code changes, so one or two >>> imports instead of a lot of find/replace (as simple as that may be) would be >>> preferable in my book. >>> >>> Derek >>> >>> >>> On Mon, Oct 19, 2009 at 8:53 PM, Naftoli Gugenheim >> > wrote: >>> What would be the purpose of having a common trait though? - Derek Chen-Becker wrote: That was pretty much what I was trying to communicate with my last email, just not very effectively. Derek On Mon, Oct 19, 2009 at 7:14 PM, Naftoli Gugenheim < naftoli...@gmail.com>wrote: > > Since there are anyway minor breaking changes in 1.1, maybe it's worth it > to take TimeHelpers out of Helpers. This way, it will simply require an > extra import, of either TimeHelpers or JodaHelpers, which can be chosen by > the individual developer. > Whenever someone is ready to migrate, they will be able to do so on a > file-by-file (or import-scope-by-import-scope) basis. > Eventually JodaHelpers could be included in Helpers. > > > - > Derek Chen-Becker wrote: > > Along those same lines, maybe there should be a common trait that doesn't > define an impl, and then have separate Joda and java.util impl traits that
[Lift] Re: Are we willing to make a breaking change for Joda Time?
Here is my argument for breaking it out: I think that we're in agreement that the *default* impl for Lift should eventually be Joda Time, after some period of deprecation on the old stuff. I also agree with your earlier comment that it should be something that the developer can choose. I'm sure there will be cases where people want to use java.util instead of Joda Time because of preference or constraint (say, no external jars). The problem is that "import Helpers._" is a very common import, and by having TimeHelpers be part of Helpers it makes it very difficult to do a clean separation of impls. My main example is the time manipulation DSL. We can't mask the implicit defs that are already part of TimeHelpers, so it's very difficult (maybe impossible) to define a Joda Time based DSL (which would properly handle things like daylight savings time, etc). By removing TimeHelpers from Helpers, it means that the user can have absolute control over which time handling impl they're using without having to give up all of the nice things in Helpers. It would be a breaking change to code, but it would be pretty minor, since the fix is just to add an import to the code that breaks. Here is my proposal for how we change things: - *version 1.1-final*: 1. Rename the current TimeHelpers trait to JavaTimeHelpers and add a new TimeHelpers trait that extends JavaTimeHelpers, providing an alias. This means no breaking code in this release. 2. Create a new JodaTimeHelpers that mirrors the non-deprecated functionality of JavaTimeHelpers (there were already some deprecated methods on TimeHelpers that could go away). 3. We can also copy back some of the new methods on JodaTimeHelpers and refactor them for java.util (I'm thinking epoch and some other minor ones). 4. Add a JavaTimeFormatting and JodaTimeFormatting trait (currently TimeRules in my code) that allows for custom formats and format functions of dates and times. The reason I want to split out the impls here, just like Java/JodaTimeHelpers, is so that Joda can be an optional dependency for people who can't use it. - *version 1.2-final*: 1. Remove the TimeHelpers trait and remove TimeHelpers from Helpers. At this point, people would have to explicitly choose JavaTimeHelpers or JodaTimeHelpers in their import statement to determine which impl they're using. The main thing is that having TimeHelpers tied to Helpers makes it very difficult to give the user a choice of impls, something that I feel strongly goes against how Lift does things otherwise. Derek On Mon, Oct 19, 2009 at 10:36 PM, David Pollak < feeder.of.the.be...@gmail.com> wrote: > I have a strong preference not to break the TimeHelpers out of Helpers. > I'm not seeing the problem with additional methods on TimeHelpers that do > the JodaTime thing. Can you guys help me understand your point of view. > > > On Mon, Oct 19, 2009 at 8:16 PM, Derek Chen-Becker > wrote: > >> Oh, that was a sidetrack. I was thinking that it could help enforce the >> common contract, but return types are different for the same method names so >> that really wouldn't work. I really just want to try and separate them out, >> or provide a different "Helpers" that provides JodaTime stuff under the same >> method names. My goal is really to minimize code changes, so one or two >> imports instead of a lot of find/replace (as simple as that may be) would be >> preferable in my book. >> >> Derek >> >> >> On Mon, Oct 19, 2009 at 8:53 PM, Naftoli Gugenheim >> wrote: >> >>> >>> What would be the purpose of having a common trait though? >>> >>> - >>> Derek Chen-Becker wrote: >>> >>> That was pretty much what I was trying to communicate with my last email, >>> just not very effectively. >>> >>> Derek >>> >>> On Mon, Oct 19, 2009 at 7:14 PM, Naftoli Gugenheim >> >wrote: >>> >>> > >>> > Since there are anyway minor breaking changes in 1.1, maybe it's worth >>> it >>> > to take TimeHelpers out of Helpers. This way, it will simply require an >>> > extra import, of either TimeHelpers or JodaHelpers, which can be chosen >>> by >>> > the individual developer. >>> > Whenever someone is ready to migrate, they will be able to do so on a >>> > file-by-file (or import-scope-by-import-scope) basis. >>> > Eventually JodaHelpers could be included in Helpers. >>> > >>> > >>> > - >>> > Derek Chen-Becker wrote: >>> > >>> > Along those same lines, maybe there should be a common trait that >>> doesn't >>> > define an impl, and then have separate Joda and java.util impl traits >>> that >>> > don't mix directly into Helpers. >>> > >>> > On Mon, Oct 19, 2009 at 6:57 PM, Derek Chen-Becker < >>> dchenbec...@gmail.com >>> > >wrote: >>> > >>> > > What I was thinking earlier is that we can simply make a JodaHelpers >>> > object >>> > > that mixes in JodaTimeHelpers instead of TimeHelpers. That wa
[Lift] Re: scalajpa - wrong database?
Which liftweb version are you using ? I've signaled a bug a few month ago, it was very very quickly fixed (thank you again Derek for your reactivity !). My jpa apps are in production and I have no such issue remaining, scalajpa looks like to be very stable. Once, I wrongly specified a wrong "persistence-unit/@name" value in test mode, and it caused the same symptoms. Have you verified that your LocalEMF configuration suits your META-INF/persistence.xml file ? Maybe you want to copy / paste your source code for a quick review ? Jean-Luc 2009/10/19 TSP > > I'm using scalajpa and have just downloaded source from github > My application has 2 databases and my unit tests are creating tables > for the second database in the first. > This was a reported issue back around June I think, but the posts seem > to imply it was fixed. > Was it not? > Thanks > Tim > > > -- Jean-Luc Canela jlcane...@gmail.com --~--~-~--~~~---~--~~ 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] net.liftweb.widgets.autocomplete in version 1.1-M6
Hi,
Previously i was working on version 1.1-M3 of lift framework and i
used autocomplete widget by override _toForm method in my Test.scala
file. It was something like that:
object Test extends Test with KeyedMetaMapper[Long, Test] with CRUDify
[Long,Test] {
(...)
}
class Test extends KeyedMapper[Long, Test] {
(...)
object TestTable extends MappedLongForeignKey(this, TestTable) {
def handleSubmit( string : String) = {
}
override def _toForm = Full( AutoComplete("", (current, limit)
=> {
TestTable.findAll.toList.map(d => (d.name.is)) },
handleSubmit ))
}
(...)
}
But now, after upgrade lift to version 1.1-M6, i'm getting this error:
error: type mismatch;
found : scala.xml.NodeSeq
required: scala.xml.Elem
override def _toForm = Full( AutoComplete("", (current,
limit) => {
^
one error found.
I can't find way to fix this problem. Could Anyone help me?
Thanks and regards
--~--~-~--~~~---~--~~
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] get warnings for every request
Hi all. When using , the result page is fine as I wished, yet these warnings run into the log for every request: WARN - Unused binding values for : content, main WARN - Unused binding values for : sidebar, main WARN - Unused binding values for : sidebar Am I missing something, or, can I disable these warnings? The lift version is 1.1-M6, template code are like below: templates-hidden/someLayout.html ...begin stuff ...between stuff ...end stuff somePage.html ...sidebar stuff ...content stuff --~--~-~--~~~---~--~~ 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: Problem with default Connection pool/CP for use with lift?
On Tue, Oct 20, 2009 at 10:34 AM, Jeppe Nejsum Madsen wrote:
> David Pollak writes:
>
>> At least the most recent version of Boot.scala has reasonable testing of
>> connection validity:
>>
>> case x :: xs => try {
>> x.setAutoCommit(false)
>> Full(x)
>> } catch {
>> case e => try {
>> pool = xs
>> poolSize = poolSize - 1
>> x.close
>> newConnection(name)
>> } catch {
>> case e => newConnection(name)
>> }
>> }
>>
>> If the setAutoCommit(false) line fails, the connection is returned to the
>> pool. You can put other logic here.
>
> Ok, I just made this change and added some logging around new/Release. I
> was a little surprised to see that newConnection is called three times
> for each request. Is this intentional?
Sorry, to keep adding to this thread, but I looked a little more in
the archetype implementation of ConnectionManager, and to me, it seems
like it is broken in several ways and will eventually lead to an OOME:
I think the logic is that pool should contain the list of connections
available for use by a request and not all the connections created?
But it seems like the implementation mix those two views:
First time through, pool is Nil so we match the first case statement,
create a new connection _AND ADD IT TO POOL_. First error: we return
the connection (ie it is in use) but still add it to the list of free
connections. Another request coming in while we process this request,
will get the same connection.
When releasing the connection, we add the released connection to the pool. Fine.
Next time, pool is not Nil so we match the x::xs case and return x.
Second error: we don't update pool to xs, x is still available for any
request coming in while we're using this connection.
And since connections are never removed from pool under normal
circumstances but always added on release, the pool list just keeps
growing.
I'll post an updated version soon
/Jeppe
--~--~-~--~~~---~--~~
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: Problem with default Connection pool/CP for use with lift?
David Pollak writes:
> At least the most recent version of Boot.scala has reasonable testing of
> connection validity:
>
> case x :: xs => try {
> x.setAutoCommit(false)
> Full(x)
> } catch {
> case e => try {
> pool = xs
> poolSize = poolSize - 1
> x.close
> newConnection(name)
> } catch {
> case e => newConnection(name)
> }
> }
>
> If the setAutoCommit(false) line fails, the connection is returned to the
> pool. You can put other logic here.
Ok, I just made this change and added some logging around new/Release. I
was a little surprised to see that newConnection is called three times
for each request. Is this intentional?
I have S.addAround(DB.buildLoanWrapper) in boot, which I assumed would
wrap each request with a transaction and thus use the same connection
for the duration of the request? I've verified that the same connection
is used on two requests executing at the same time which sounds a bit
scary
Did I miss something?
/Jeppe
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: How to disable a textfield
Change -> to -%>
Doing this preserves any element attributes, for example:
disabled="disabled"
Cheers, Tim
On Oct 20, 6:30 am, sunanda wrote:
> Hi,
> I need to disable all the textfield and then want to enable the fields
> for editing on click of a button.
> How can i do this with the following sample code.
> Thanks
> Regards,
> Sunanda.
>
> bind("add",html,
> "displayname"->coldef.displayname.toForm,
> "columntype"->coldef.coltype.toForm,
> "sourceview"->coldef.sourceview.toForm)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
