Re: [Lift] Customizing meta fields
Again, thank you so much for the help! The head merge feature is perfect for
this situation i described and my next line of though is right inline with
how you describe bind points!
Thanks again!
-- Martin
On Mon, Mar 8, 2010 at 12:47 PM, Ross Mellgren dri...@gmail.com wrote:
For your particular example, you can use head merge as Naftoli suggests.
Head merge is a behavior of Lift templates where any head tags will be
merged together for the final output, so you put your meta
name=description in each of the specific places, any general head stuff
you want in your surrounding template and they will magically get folded
together at render time.
For other cases, you have a couple tools at your disposal:
- RequestVars -- variables that are local to a particular page request.
You can use these inside snippets to capture and recover values during
template processing.
- Bind points. In a surrounding template you can use tags like lift:bind
name=foobar / and then define what to put there in the surrounded
template using lift:bind-at name=foobarthe content/lift:bind-at
And there are more. Hopefully head merging will work for you in this case.
-Ross
On Mar 7, 2010, at 8:25 PM, Martin Dale Lyness wrote:
Thank you Ross, for the very informative response!
Now, I consider SEO to be closer to a designer task than a developer task
so keeping the power in the design documents would be my best idea. Is there
anyway to allow individual pages to define blocks that are read into the
snippets and then injected into the template?
Here is the scenario i'm thinking of:
1. A single uniform website template: default.html
2. Several HTML files: index.html, product_list.html, product_overview.html
3. Each of these HTML files containing lift:xxx tags referencing
snippets.
What i would want is for index.html, product_list.html, and
product_overview.html to all use default.html and various Snippet classes.
Now for SEO i would want the meta tags in the header of default.html to be
customized to index.html, product_list.html, and product_overview.html;
furthermore, product_list and product_overview are dynamic pages so they
would need further customization based on what the snippets are returning.
Essentially, i would want tags something like:
lift:meta_descThis site is totally awesome, better than all our
competitors/lift:meta_desc in index.html
lift:meta_descLook at all these products in
%%category_name%%/lift:meta_descin product_list.html
lift:meta_desc%product_name% - %product_description%/lift:meta_desc
in product_overview.html
The conceptual road block for me is coming from the controller first
pattern used in frameworks like Rails. In lift snippets are not really the
same conceptually. If i use the second proposed method
(i.e. lift:HelloWorld.hello wrapping the entire template) i would have a
battle between snippets used by each page. For example, perhaps i have a
product overview snippet that sets the meta one way and a login snippet that
sets it another way (intended for when show standalone in a login.html).
The first solution with using a lift:HelloWorld.funcName / to inject a
snippet at a meta location fits better because it would allow me to create a
generic function that would attempt to create the keyword and description
data based on whatever global information is made available to snippets by
lift (i.e. Request Parameters?). My only problem with using this option is
it puts all of the text on the developer side forcing the dev team to update
descriptions and keywords where really the designers should be doing this.
Does anyone have a suggestion on how to put the power in the hands of the
designers in this type of situation?
-- Martin
On Sun, Mar 7, 2010 at 6:17 PM, Ross Mellgren dri...@gmail.com wrote:
To be parsed by the bind, it must be enclosed by
lift:HelloWorld.hello.../lift:HelloWorld.hello
There is relatively little magic -- Lift goes through your template
looking for lift: prefixed tags. For those tags, it will look up a snippet
class by using the part before the period (HelloWorld, in the above example)
and then look for a method on that snippet class mentioned after the period
(hello in the example). If there is no period, the method is assumed to be
called render.
Once that method is found, the method is called with the contents of the
lift: tag, and the result of the method call is spliced into the XML to
replace the lift: tag.
bind is a function that does something kind of similar to overall template
processing, except you supply some prefix other than lift: (b: in the
example) and a limited set of things after the colon that are valid (time
and meta_desc in the example)
So, you might want something like this instead:
meta name=descriptionlift:HelloWorld.meta_desc //meta
class HelloWorld {
def meta_desc(ns: NodeSeq): NodeSeq = Text(test desc)
}
Which
[Lift] Customizing meta fields
How would one go about having dynamic description and keyword meta tags in a template? Here is what i've tried: default.html meta name=descriptionb:meta_desc //meta HelloWorld.scala Helpers.bind(b, in, time - date.map(d = Text(d.toString)), meta_desc - test desc) I'm using a basic archetype build of 2.0-M3 and it produces an error: This page contains the following errors: error on line 6 at column 28: Namespace prefix b on meta_desc is not defined Below is a rendering of the page up to the first error. It appears to me that the template is not parsed by the Helpers.bind, is this correct? -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Activity
Hey, First of all, let me take the complete opposite stance observed from one of the most reason posts from a Rails Junkie. I'm very excited to see a framework that takes the good from so many different projects and houses it under a language that does the same. I find it refreshing to have the powerful tools developed around Java available for development in this new Scala language and the Lift framework. No matter how much one hates the design choices and the verbosity of the most popular platform in our lifetime, it is only a benefit that we have access to the years of effort devoted to it. The powerful compiler behind Scala is my sole reason for preferring it to ports like JRuby and Groovy. Now to the point of my query, what is the activity and excitement levels around lift at this point? I understand that money drives the world and to make a framework successful one must market like Rails and make some bank to promote future maintenance and improvements. I notice the last production quality release was over a year ago; I do notice there have been much more frequent updates to say the wiki and the work on the 1.1 milestones. It just seems strange that a minor release on such a young project would taking such a long time. This is a completely naive view of what is going on, and this is why i post this query because I want to be disproven so I can feel comfortable suggesting the use of this framework for the long term. Thanks for letting me take some of your time away from more important things :). I just figured seeing this was a question in my mind, others thinking about using the framework might have the same question. -- Martin -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Customizing meta fields
Thank you Ross, for the very informative response!
Now, I consider SEO to be closer to a designer task than a developer task so
keeping the power in the design documents would be my best idea. Is there
anyway to allow individual pages to define blocks that are read into the
snippets and then injected into the template?
Here is the scenario i'm thinking of:
1. A single uniform website template: default.html
2. Several HTML files: index.html, product_list.html, product_overview.html
3. Each of these HTML files containing lift:xxx tags referencing snippets.
What i would want is for index.html, product_list.html, and
product_overview.html to all use default.html and various Snippet classes.
Now for SEO i would want the meta tags in the header of default.html to be
customized to index.html, product_list.html, and product_overview.html;
furthermore, product_list and product_overview are dynamic pages so they
would need further customization based on what the snippets are returning.
Essentially, i would want tags something like:
lift:meta_descThis site is totally awesome, better than all our
competitors/lift:meta_desc in index.html
lift:meta_descLook at all these products in
%%category_name%%/lift:meta_descin product_list.html
lift:meta_desc%product_name% - %product_description%/lift:meta_desc
in product_overview.html
The conceptual road block for me is coming from the controller first pattern
used in frameworks like Rails. In lift snippets are not really the same
conceptually. If i use the second proposed method
(i.e. lift:HelloWorld.hello wrapping the entire template) i would have a
battle between snippets used by each page. For example, perhaps i have a
product overview snippet that sets the meta one way and a login snippet that
sets it another way (intended for when show standalone in a login.html).
The first solution with using a lift:HelloWorld.funcName / to inject a
snippet at a meta location fits better because it would allow me to create a
generic function that would attempt to create the keyword and description
data based on whatever global information is made available to snippets by
lift (i.e. Request Parameters?). My only problem with using this option is
it puts all of the text on the developer side forcing the dev team to update
descriptions and keywords where really the designers should be doing this.
Does anyone have a suggestion on how to put the power in the hands of the
designers in this type of situation?
-- Martin
On Sun, Mar 7, 2010 at 6:17 PM, Ross Mellgren dri...@gmail.com wrote:
To be parsed by the bind, it must be enclosed by
lift:HelloWorld.hello.../lift:HelloWorld.hello
There is relatively little magic -- Lift goes through your template looking
for lift: prefixed tags. For those tags, it will look up a snippet class by
using the part before the period (HelloWorld, in the above example) and then
look for a method on that snippet class mentioned after the period (hello in
the example). If there is no period, the method is assumed to be called
render.
Once that method is found, the method is called with the contents of the
lift: tag, and the result of the method call is spliced into the XML to
replace the lift: tag.
bind is a function that does something kind of similar to overall template
processing, except you supply some prefix other than lift: (b: in the
example) and a limited set of things after the colon that are valid (time
and meta_desc in the example)
So, you might want something like this instead:
meta name=descriptionlift:HelloWorld.meta_desc //meta
class HelloWorld {
def meta_desc(ns: NodeSeq): NodeSeq = Text(test desc)
}
Which will result in this XHTML:
meta name=descriptiontest desc/meta
Or, if you want to keep it in the hello method, you'd then have to move the
lift:HelloWorld.hello to the outside of the template:
lift:HelloWorld.hello
...
head
meta name=descriptionb:meta:desc //meta
/head
...
b:time /
/lift:HelloWorld.hello
Hope that helps,
-Ross
On Mar 7, 2010, at 4:38 AM, Martin wrote:
How would one go about having dynamic description and keyword meta
tags in a template? Here is what i've tried:
default.html
meta name=descriptionb:meta_desc //meta
HelloWorld.scala
Helpers.bind(b, in, time - date.map(d = Text(d.toString)),
meta_desc - test desc)
I'm using a basic archetype build of 2.0-M3 and it produces an error:
This page contains the following errors:
error on line 6 at column 28: Namespace prefix b on meta_desc is not
defined
Below is a rendering of the page up to the first error.
It appears to me that the template is not parsed by the Helpers.bind,
is this correct?
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr
[Lift] reload application.properties
Hi is there any way to reload application.properties file after boot.scala finishes? I would like to do dynamic localization of properties on my site, without need to stop/start application. Mayby there is much better way to accomplish it. I would really appreciate any help. best regards, Martin -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] anybody used OPA?
On 22 February 2010 21:45, Raoul Duke rao...@gmail.com wrote: This is related to Lift how? It appears to be a framework itself... i figure people who use Lift are the kinds of people who might have their ear to the ground for other approaches to the web problem, and might have insight into Competitor X, Y, or Z. i've certainly seen people talk about other Java solutions before, admittedly ML is further afield, although given Scala, not that much. I must admit, my initial interest in Scala came from prior use of ML. I can't answer your question, I'm afraid, but can offer some other links you might find interesting if you haven't seen them already: Ur/Web - web application language/framework. http://impredicative.com/ur/ Yeti - ML-like language on the JVM. http://wiki.github.com/mth/yeti/ Martin -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] OSGi example, what to do to make it run?
On 5 February 2010 05:00, philip philip14...@gmail.com wrote: I downloaded the git source and made a OSGi jar package by running the maven, now what do I do with it? I see its a jar file with the manifest for OSGi, I guess I can load it into Apache Felix, but doesn't Liftweb need tomcat or jetty to run? So I don't really understand how its going to run. I've also puzzled over this. I've figured out that you can point pax-runner at the hello.composite file. I'd love to see a tutorial on how experienced OSGI developers set up their the development environment, and how they work the edit/compile/redeploy cycle. It's very obvious for mvn jetty:run (just wait for the scanner, or use JavaRebel). It's not so obvious how people work with OSGI containers. The best I've figured is to use the pax assembly: stuff to point at target classes, and run update bundle-id for each edit/compile cycle - it's a bit clunky. Any offers/suggestions? (Sorry, I realise the question more about OSGI than lift) Martin -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [scala-internals] RC8 candidate for the first 2.8.0 beta
(Un)fortunately I have an idea what the problem is. It's probably my fix for #2867. I have now rolled back that fix in r20629. Can you check again whether it works with that revision (should be in the nightly tomorrow)? If it does we might be able to make an exception to our RC = final rule, because this one just rolls back a non-critical patch, so I fail to see how this could affect anything but the original ticket. Cheers -- Martin -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [scala-internals] RC8 candidate for the first 2.8.0 beta
On Thu, Jan 21, 2010 at 8:31 PM, David Pollak feeder.of.the.be...@gmail.com wrote: I've written a work-around and am currently testing the code more in a few minutes. If you can make it work, so much the better. To give some info: The original ticket had a vararg parameter of the form List[_]* in a case class. This caused type inference for the synthetic equals method (which uses sameElements for varargs) to fail, because the existential in List[_] made the problem underconstrained. The patch passed the argument type explicitly as the type parameter. In the lift case, it seems that this explicit type parameter violated some type bound, so the type inferencer should have chosen a more general type which would not violate the bound. The easiest fix is probably to just roll back and leave ticket #2867 open until we find a better solution. That's what I have done. Cheers -- Martin -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [scala-internals] RC8 candidate for the first 2.8.0 beta
On Thu, Jan 21, 2010 at 8:37 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Okay... the work-around is checked into the Lift repo. I say, Ship RC8 as the beta and we'll work through this (and likely other) issues during the beta period. Sounds good. Thanks! -- Martin On Thu, Jan 21, 2010 at 11:36 AM, martin odersky martin.oder...@epfl.ch wrote: On Thu, Jan 21, 2010 at 8:31 PM, David Pollak feeder.of.the.be...@gmail.com wrote: I've written a work-around and am currently testing the code more in a few minutes. If you can make it work, so much the better. To give some info: The original ticket had a vararg parameter of the form List[_]* in a case class. This caused type inference for the synthetic equals method (which uses sameElements for varargs) to fail, because the existential in List[_] made the problem underconstrained. The patch passed the argument type explicitly as the type parameter. In the lift case, it seems that this explicit type parameter violated some type bound, so the type inferencer should have chosen a more general type which would not violate the bound. The easiest fix is probably to just roll back and leave ticket #2867 open until we find a better solution. That's what I have done. Cheers -- Martin -- 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On Tue, Dec 22, 2009 at 2:01 PM, Josh Suereth joshua.suer...@gmail.com wrote: I think staying in maven would require the least amount of typing, but the most amount of time as you'd have to publish local snapshots of Scala 2.8.0 to use them in the lift build. I remember how annoying this is ;). Also note that deploying maven requires a full scala build, but if needed I can make a short-cut that will just publish the quick libraries. This would help immensely in testing trunk against projects, but is not very helpful otherwise. Would this be desirable? What was already suggested (runing mvn dependency:copy-dependencies) is very viable. However, if lift-mapper relies on lift-util, you'll have to rebuild one before you rebuild the other if you're somehow changing the ABI. If you still wanted to use maven, I recommend using the reactor plugin. If you identify the project that is failing you can run: mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper Where net.liftweb:lift-mapper is the groupId:artifactId containing the failing module. This will only build the lift-mapper module and other modules on which lift-mapper depends (i.e. if lift-mapper needs lift-util (and only lift-util) just those two will be built. I have a local VM where I was setting up a scala nightly build that would feed maven. Perhaps when I finish I'll make a write-up on how to do this, or have some kind of template/script you can use to do it by hand. - Josh Hi Josh, The problem is not so much building individual maven modules, but building them with experimental compilers. I need to be able to put a println into scalac, rebuild that (takes 10sec with fsc) and then recompile the offending maven part with that compiler. That's why I need a version of lift that can be compiled without maven. It need not be perfect, for instance one can probably throw out all the tests. But I need to be able to use lift as a rapid experimentation tool for the scala compiler itself. Unfortunately, LAMP is pretty much shutting down for the holidays right now. So any outside help that you can give is appreciated. Ideally: I get the right lift version as a tarball, together with all jars that it needs. Then, instructions what to compile in what order (I can probably figure them out in a pinch, but if someone knows that already, it would help). Thanks -- Martin -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On Tue, Dec 22, 2009 at 2:35 PM, Josh Suereth joshua.suer...@gmail.com wrote: For curiousities sake, if you're building using fsc, are you running scalac via an exploded classpath (i.e. not a JAR file?). If so, I'll try to come up with a longer-term solution for this. Yes, exactly. My usual setup is that my output directory is the first item on the classpath. So any files I recompile get chosen first. If we allowed you to do the following: mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper -P local-scala -Dscala.local.classpath=classfiledir would that be sufficient? We could also have this do conditional computation in the future. Does that mean that the scala compiler would then be run out of classfiledir? Yes, that could work. Cheers -- Martin -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On Tue, Dec 22, 2009 at 3:41 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: Martin, OK, now I got it working (almost) without Maven: 1. step: Check out 280_port branch from ...@github.com:dpp/liftweb.git 2. step: cd into liftweb/lift-persistence/lift-mapper and run mvn dependency:copy-dependencies 3. step: run the following command PATH-TO-SCALAC-OR-FSC-2.8-BETA1-RC5 -classpath `find target/dependency -name *.jar | xargs scala -e 'println(args mkString :)'` -sourcepath src/main/scala -d target/classes `find src/main/scala -name *.scala` This will only use Maven to download the dependencies, but you can compile with scalac or fsc. Great! Can you provide me with a tarball or zip of the lift sources? I don't have git installed here yet. Thanks -- Martin -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
Thanks for all the help. I tried to do mvn clean mvn install After upgrading to maven 2.2.1, I got somewhere. It compiled a bunch of packages including lift-mapper, so it seems it did not in fact take RC6 as its compiler? But then it stopped due to a build error here. Any idea what I need to do to solve this? Thanks -- martin [INFO] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] [INFO] [INFO] Failed to resolve artifact. [INFO] [INFO] Couldn't find a version in [6.1H.22, 6.1.17, 6.1.18, 6.1.19, 6.1.20, 6.1.21, 6.1.22] to match range [6.1.6,6.1.6] [INFO] org.mortbay.jetty:jetty:jar:null [INFO] [INFO] from the specified remote repositories: [INFO] scala-tools.org (http://scala-tools.org/repo-releases), [INFO] central (http://repo1.maven.org/maven2), [INFO] scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots) [INFO] [INFO] Path to dependency: [INFO] 1) test:sample:war:0.1 [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] Trace [INFO] org.apache.maven.lifecycle.LifecycleExecutionException: Couldn't find a version in [6.1H.22, 6.1.17, 6.1.18, 6.1.19, 6.1.20, 6.1.21, 6.1.22] to match range [6.1.6,6.1.6] [INFO] org.mortbay.jetty:jetty:jar:null [INFO] [INFO] from the specified remote repositories: [INFO] scala-tools.org (http://scala-tools.org/repo-releases), [INFO] central (http://repo1.maven.org/maven2), [INFO] scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots) [INFO] [INFO] Path to dependency: [INFO] 1) test:sample:war:0.1 [INFO] [INFO] [INFO] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:711) [INFO] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) [INFO] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) [INFO] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) [INFO] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) [INFO] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) [INFO] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) [INFO] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) [INFO] at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) [INFO] at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) [INFO] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [INFO] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [INFO] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [INFO] at java.lang.reflect.Method.invoke(Method.java:597) [INFO] at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) [INFO] at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) [INFO] at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) [INFO] at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] Caused by: org.apache.maven.artifact.versioning.OverConstrainedVersionException: Couldn't find a version in [6.1H.22, 6.1.17, 6.1.18, 6.1.19, 6.1.20, 6.1.21, 6.1.22] to match range [6.1.6,6.1.6] [INFO] org.mortbay.jetty:jetty:jar:null [INFO] [INFO] from the specified remote repositories: [INFO] scala-tools.org (http://scala-tools.org/repo-releases), [INFO] central (http://repo1.maven.org/maven2), [INFO] scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots) [INFO] [INFO] Path to dependency: [INFO] 1) test:sample:war:0.1 [INFO] [INFO] [INFO] at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:374) [INFO] at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74) [INFO] at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:316) [INFO] at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:304) [INFO] at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1499) [INFO] at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:442) [INFO] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) [INFO] ... 17 more [INFO] [INFO] [INFO] [INFO] Total time: 6 seconds [INFO] [INFO] Finished at: Tue Dec 22 17:26:55 CET 2009 [INFO] [INFO] Final Memory: 12M/127M [INFO] [INFO
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
I just verified that it did indeed use 2.7.7, because the generated classfiles still have version 4.1. My new strategy is to build with the last working RC3, and then recompile just the failing file with the current compiler and all lift classes on the classpath. That should work. But I need to know how to build lift with a 2.8.0 compiler. Or alternatively, if a kind soul can send me a lift 2.8.0 tarball with all the classfiles in there I can take it from there. Thanks -- Martin -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri indraj...@gmail.com wrote: Martin, I think the jetty version is incorrect in the pom.xml in test:sample. It should be: groupIdorg.mortbay.jetty/groupId artifactIdjetty/artifactId version[6.1.6,7.0)/version See if that works. But even then I only get a 2.7.7 build, which is not what I need? -- Martin -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri indraj...@gmail.com wrote: Martin, I think the jetty version is incorrect in the pom.xml in test:sample. It should be: groupIdorg.mortbay.jetty/groupId artifactIdjetty/artifactId version[6.1.6,7.0)/version ... and, which test:sample are you referring to? Thanks -- Martin -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On Tue, Dec 22, 2009 at 6:24 PM, Indrajit Raychaudhuri indraj...@gmail.com wrote: On 22/12/09 10:44 PM, martin odersky wrote: On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri indraj...@gmail.com wrote: Martin, I think the jetty version is incorrect in the pom.xml in test:sample. It should be: groupIdorg.mortbay.jetty/groupId artifactIdjetty/artifactId version[6.1.6,7.0)/version ... and, which test:sample are you referring to? Thanks -- Martin The test:sample:war:0.1 artifact for which it fails. By your question, I realize that you are encountering this during archetype generation. It's completely unnecessary. edit the top level pom.xml and remove all the modules other than lift-base, lift-persistence and lift-modules for now. They are really all that you need. The modules section in your top level pom.xml should have just this. modules modulelift-base/module modulelift-persistence/module modulelift-modules/module !--modulelift-archetypes/module-- !--modulelift-examples/module-- !-- the 'meta' module -- !--modulelift-core/module-- /modules - Indrajit OK, that will help, I hope. But I still have no luck. When I download from http://github.com/dpp/liftweb/tree/280_port I get something that's different than the layout on the webpage. Subdirectories in dpp-liftweb-12d1bf0/ are flatter than what I see on the webpage. When I compile with 2.8 it dies because it wants jcl.Conversions which sure does not exist anymore. So it seems to me that versions are mixed up? I really need a tarball or zip with the right lift to test against! -- Martin -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
I found someone who could download the repository with git. So trying again now. -- Martin On Tue, Dec 22, 2009 at 6:36 PM, martin odersky martin.oder...@epfl.ch wrote: On Tue, Dec 22, 2009 at 6:24 PM, Indrajit Raychaudhuri indraj...@gmail.com wrote: On 22/12/09 10:44 PM, martin odersky wrote: On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri indraj...@gmail.com wrote: Martin, I think the jetty version is incorrect in the pom.xml in test:sample. It should be: groupIdorg.mortbay.jetty/groupId artifactIdjetty/artifactId version[6.1.6,7.0)/version ... and, which test:sample are you referring to? Thanks -- Martin The test:sample:war:0.1 artifact for which it fails. By your question, I realize that you are encountering this during archetype generation. It's completely unnecessary. edit the top level pom.xml and remove all the modules other than lift-base, lift-persistence and lift-modules for now. They are really all that you need. The modules section in your top level pom.xml should have just this. modules modulelift-base/module modulelift-persistence/module modulelift-modules/module !--modulelift-archetypes/module-- !--modulelift-examples/module-- !-- the 'meta' module -- !--modulelift-core/module-- /modules - Indrajit OK, that will help, I hope. But I still have no luck. When I download from http://github.com/dpp/liftweb/tree/280_port I get something that's different than the layout on the webpage. Subdirectories in dpp-liftweb-12d1bf0/ are flatter than what I see on the webpage. When I compile with 2.8 it dies because it wants jcl.Conversions which sure does not exist anymore. So it seems to me that versions are mixed up? I really need a tarball or zip with the right lift to test against! -- Martin -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On Tue, Dec 22, 2009 at 7:12 PM, Paul Phillips pa...@improving.org wrote: On Tue, Dec 22, 2009 at 05:45:52PM +0100, martin odersky wrote: But I need to know how to build lift with a 2.8.0 compiler. Or alternatively, if a kind soul can send me a lift 2.8.0 tarball with all the classfiles in there I can take it from there. FYI until you have git you can always download a tarball snapshot of the current head at github. There's a download link here: http://github.com/dpp/liftweb Except you need the 280_port branch, so here: http://github.com/dpp/liftweb/tree/280_port And that download link goes here: http://github.com/dpp/liftweb/tarball/12d1bf0697c9c792c8c91416989a0ef7e287b156 Assuming that gets the files it should, typing mvn install will try to build with 2.80 Beta1 RC3. To use RC5 edit pom.xml with this diff: - scala.version2.8.0.Beta1-RC3/scala.version + scala.version2.8.0.Beta1-RC5/scala.version Instructions from earlier in this thread should get you to the point where you can build with the local compiler. yes I got that working. The problem was that the download at 280_port was not 280_port but (I guess) 280_dev. That got me stuck for a while, but we sorted it out eventually. Cheers -- Martin -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [scala-internals] RC4 candidate for the first 2.8.0 beta
On Sun, Dec 20, 2009 at 12:39 PM, martin odersky martin.oder...@epfl.ch wrote: Thanks for letting us know. This looks like something stirred up by the change in erasure. We'll investigate Monday what it is. Cheers -- Martin I could reproduce the fault and think I found the underlying problem: There was a problem with the erasure of self types and it looks like this problem was unmasked by my previous, unrelated change to erasure. I'll think about a fix now. Cheers -- Martin -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [scala-internals] RC4 candidate for the first 2.8.0 beta
Thanks for letting us know. This looks like something stirred up by the change in erasure. We'll investigate Monday what it is. Cheers -- Martin On Sun, Dec 20, 2009 at 11:43 AM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: Lift built against RC3, but with RC4 we get this error: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.scala_tools.maven.executions.MainHelper.runMain(MainHelper.java:151) at org.scala_tools.maven.executions.MainWithArgsInFile.main(MainWithArgsInFile.java:26) Caused by: java.lang.AssertionError: assertion failed: type error: can't convert from REFERENCE(net.liftweb.util.StringHelpers) to REFERENCE(net.liftweb.util.BasicTypesHelpers) in unit BasicTypesHelpers.scala at scala.tools.nsc.backend.icode.GenICode$ICodePhase.adapt(GenICode.scala:943) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:927) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadLabelArguments(GenICode.scala:990) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:710) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadIf(GenICode.scala:363) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:511) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadIf(GenICode.scala:363) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:511) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:484) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:850) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:130) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97) at scala.collection.immutable.List.foreach(List.scala:46) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:152) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:106) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97) at scala.collection.immutable.List.foreach(List.scala:46) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:97) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97) at scala.collection.immutable.List.foreach(List.scala:46) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:97) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:83) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.apply(GenICode.scala:79) at scala.tools.nsc.Global$GlobalPhase$$anonfun$applyPhase$1.apply(Global.scala:281) at scala.tools.nsc.Global$GlobalPhase$$anonfun$applyPhase$1.apply(Global.scala:281) at scala.tools.nsc.reporters.Reporter.withSource(Reporter.scala:48) at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:281) at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:259) at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:259) at scala.collection.Iterator$class.foreach(Iterator.scala:582) at scala.collection.mutable.ListBuffer$$anon$1.foreach(ListBuffer.scala:285) at scala.tools.nsc.Global$GlobalPhase.run(Global.scala:259) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.run(GenICode.scala:72) at scala.tools.nsc.Global$Run.compileSources(Global.scala:749) at scala.tools.nsc.Global$Run.compile(Global.scala:839) at scala.tools.nsc.Main$.process(Main.scala:109) at scala.tools.nsc.Main$.main(Main.scala:123) at scala.tools.nsc.Main.main(Main.scala) ... 6 more Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me
[Lift] Problems downloading dependencies, can't get started
Hi- I was very intrigued with Lift, so I tried to work my way through the Hello World tutorial. Unfortunately, I can't seem to get that to work. I'm running on Snow Leopard. I installed Lift with the installer downloaded from the Lift web site (version 1.0.1). When I first ran mvn jetty:run it tried to download a bunch of dependencies. Unfortunately, I was in china on a business trip when this happened, and because of my spotty internet connection, I don't think all the dependencies downloaded, and I couldn't launch the hello world tutorial. Now, I'm back in the states, but I can't figure out how to get Maven to retry downloading the dependencies. All that happens when I type mvn jetty:run is: [INFO] Copying 0 resource [WARNING] POM for 'backport-util-concurrent:backport-util- concurrent:pom:3.0:runtime' is invalid. Its dependencies (if any) will NOT be available to the current build. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error configuring: net.sf.alchim:yuicompressor-maven-plugin. Reason: A required class was missing during mojo configuration: org/ mozilla/javascript/ErrorReporter [INFO] [INFO] For more information, run Maven with the -e switch Can anyone give me some advice on fixing this? Thanks, Nate --~--~-~--~~~---~--~~ 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: Problems downloading dependencies, can't get started
Fantastic, that worked great! Mentioning this tip in the tutorial might be a good idea. Thanks! On Nov 14, 4:37 pm, Jim Barrows jim.barr...@gmail.com wrote: Nate there is a directory in your home directory called .m2. Delete that and retry. If that doesn't work, and nobody else jumps in, its an issue with maven. I'm mobile abd be more helpful I'm afraid. Sent on the Now Network™ from my Sprint® BlackBerry -Original Message- From: Nate Martin natmar...@gmail.com Date: Sat, 14 Nov 2009 16:32:19 To: Liftliftweb@googlegroups.com Subject: [Lift] Problems downloading dependencies, can't get started Hi- I was very intrigued with Lift, so I tried to work my way through the Hello World tutorial. Unfortunately, I can't seem to get that to work. I'm running on Snow Leopard. I installed Lift with the installer downloaded from the Lift web site (version 1.0.1). When I first ran mvn jetty:run it tried to download a bunch of dependencies. Unfortunately, I was in china on a business trip when this happened, and because of my spotty internet connection, I don't think all the dependencies downloaded, and I couldn't launch the hello world tutorial. Now, I'm back in the states, but I can't figure out how to get Maven to retry downloading the dependencies. All that happens when I type mvn jetty:run is: [INFO] Copying 0 resource [WARNING] POM for 'backport-util-concurrent:backport-util- concurrent:pom:3.0:runtime' is invalid. Its dependencies (if any) will NOT be available to the current build. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error configuring: net.sf.alchim:yuicompressor-maven-plugin. Reason: A required class was missing during mojo configuration: org/ mozilla/javascript/ErrorReporter [INFO] [INFO] For more information, run Maven with the -e switch Can anyone give me some advice on fixing this? Thanks, Nate --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
Hi Jonas, On Sep 30, 8:05 pm, Jonas Bonér jbo...@gmail.com wrote: Hi Martin and Philipp. Thanks for your email. What you are saying sounds great. I love Scala Actors and I know its an important thing that brings people over to Scala. I hope that I didn't offend you. You have done amazing things with and for Scala. I really respect you guys. But I saw and felt the need for something like Akka and went away and build it. I think you have done a great thing with Akka, and I'm very glad you did it! That's precisely the strength of Scala that experts can build great libraries and high-level domain specific languages on it. I really like where you are taking Akka, and I hope it will be very succesfull. As I wrote before, we are not at all defensive about our own actor library. I think Scala actors are very useful for lots of people who need easy and performant support for concurrent programs. If you need to take it further (such as remoting, supervising, persistence), there might be other more complete systems like Akka that can pick up there and provide these things. We at EPFL simply do not have the contributor base to do that ourselves, and that's also not our mission, I think. We need to concentrate on core language, tools, and some core libraries (if there's nobody else doing those). So I see Akka as a very important upgrade path from simple multicore concurrency to robust distributed systems. And I hope that other people will do the same in other areas, such as I/O, serialization, graphics, and so on. If we can collaborate on those, great, but if people find it easier to do their own thing, that's also perfectly fine. The only thing I am asking is to avoid confusion to outside people. Be clear what role you API serves, how it is different from others. Avoid using the same name for different things. Cheers -- Martin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
About actors in Scala 2.8: . they have been refactored substantially compared to what's in the 2.7.x branch . Philipp has sent mails about this to scala-internals (05/31) . Philipp has invited DPP to look at the refactorings in 2.8 (07/21) to which he responded positively. . The ForkJoinPool in 2.8 is completely different from FJTask in 2.7.5; it's the version that's going into JDK7. It has been battle-tested and should not suffer from any memory leaks. The reason why Scala actors use the FJ framework is performance, in particular on multi-core hardware. So we do not think it's a good idea to go back to java.util.concurrent, except maybe for applications with very specialized demands. We think the main problem was that lift depends on Scala 2.7.x, and that the actor refactorings have not gone into the 2.7.x branch. The result is that people have not noticed the changes. For example, most of the issues that Erik raises in his blog post no longer apply to Scala 2.8. Initially we wanted 2.8 to be out by now, but it's taken much longer than we have foreseen, because some of the problems were harder than initially thought. We are sorry to have left the 2.7 branch relatively unattended for so long. It's difficult for us, though, to provide the resources to support two diverging branches in parallel. More community support with backports etc could help. To fix the concrete issue at hand, we replaced FJTask with (a backport of) java.util.concurrent.ThreadPoolExecutor in the Scala 2.7.x branch, to be released as 2.7.7. That takes care of the memory leaks in FJTask. Now to the larger picture. We are not at all wedded to Scala actors here; after all it's just a library. If there are others which fulfill some needs better, great! But we have to be honest to avoid confusion. One of the main differences between Scala actors and lift actors and Akka seems to be that only Scala actors provide nested receives, so only Scala actors really let you avoid an inversion of control. This is a feature which complicates the implementation considerably, and that's what all our main results are about. You might not care about this particular feature in your code, and consequently you might choose a different abstraction. But calling that abstraction simply `actors' causes unnecessary confusion, in our opinion. And that's not good for the goal of convincing people that actors are a useful concurrency abstraction. So, nothing against lift actors and Akka, but we need to be precise about the tradeoffs. Maybe call them `flat actors' or something like that. Martin and Philipp --~--~-~--~~~---~--~~ 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: automaticly generated forms and submit button naming
Hi,
Ross, thank you for your help. This code works perfectly for me. I
heaven't noticed I could group many elements in one lift tag.
I changed somethings in your code. Maybe it's not worth mentioning but
if someone has similar problems it can help a little.
I corrected only to things: changed parameters order in one bind and
added some code to other.
Result is here:
def newPlace(ns: NodeSeq, place : Place): NodeSeq = {
def bindFields(innerNs: NodeSeq): NodeSeq = {
var s : String = test
signupFields.
map(fi = getSingleton.getActualBaseField(place, fi)).
flatMap(f = {
f.toForm.toList.map(form = {
bind(field,
innerNs,
displayName -
f.displayName,
form-
form)(1);
})
})
}
def handleSubmit(): Any = {
}
bind(place, ns,
fields - { (ns: NodeSeq) = bindFields(ns) },
submit - { (ns: NodeSeq) = SHtml.submit(Submit new
place, handleSubmit _) })
}
Still I don't get why I need to get second element from bind result
(which is NodeSeq) and pass it to .toForm.toList.map(...).
When I first compiled this code i got type mismatch error:
found : scala.xml.NodeSeq
required: scala.xml.Node
So I picked up first non empty element from the result by using bind
(...)(1) and it works in my scenario. Maybe I will catch it later ;)
Again this code works perfectly for me. Great thanks Ross!
- Martin
On 24 Wrz, 16:15, Ross Mellgren dri...@gmail.com wrote:
It sounds like you probably want p{ SHtml.submit(Title of submit
button, () = actionToTakeWhenButtonIsUsedToSubmitForm) }/p
By the way, what you have there doesn't seem to be following the usual
lift pattern of binding snippets, is there a reason that you prefer
this to:
template:
lift:MySnippet.newPlace form=post
h4Place details/h4
div
place:fields
p
labelfield:displayName //label
field:form /
/p
/place:fields
/div
pplace:submit //p
/lift:MySnippet.newPlace
Snippet:
def newPlace(ns: NodeSeq): NodeSeq = {
val place = /* make a new place somehow */
def bindFields(ns: NodeSeq): NodeSeq =
signupFields.
map(fi = getSingleton.getActualBaseField(place, fi)).
flatMap(f = {
f.toForm.toList.map(form = {
bind(ns, field,
displayName - f.displayName,
form - form)
})
})
def handleSubmit(): Any = /* do something with place */
bind(place, ns,
fields - { (ns: NodeSeq) = bindFields(ns) },
submit - { (ns: NodeSeq) = SHtml.submit(Submit new
Place, handleSubmit _) })
}
This way lets you see most of the HTML in one place (the template). I
inlined localForm, but there's no particular reason that it needs to
be local (other than it closes on place, but you could just pass that
in)
-Ross
On Sep 24, 2009, at 6:55 AM, Martin wrote:
Hi all,
I've got a following problem. When I create a form form automaticly..
similar to the User login/register example I encontered a problem I'm
not posible to cope with.
Firstly I have 'written' a function (using CopyPaste method) which
creates a form fields list based on my class properties:
private def localForm(place: Place, ignorePassword: Boolean):
NodeSeq = {
signupFields.
map(fi = getSingleton.getActualBaseField(place, fi)).
filter(f = !ignorePassword || (f match {
case f: MappedPassword[Place] = false
case _ = true
})).
flatMap(f =
f.toForm.toList.map(form = plabel{f.displayName}/
label {form}/p) )
}
Next, I wrote some code to return a complete form to the snippet:
def newPlace(place: Place) =
form method=post action={S.uri}
h4Place details/h4
div
{
localForm(place, false)
}
/div
p_WHAT_SHOULD_I_WRITE_HERE_:submit //p
/form
My question is... what do I write in _WHAT_SHOULD_I_WRITE_HERE_ ?
Or better.. how/where to define this value?
In a user login/register example there is submit defined like this:
user:submit
Placing there name of the owner class didn't work.
I know I could use bind but as far as I know next I should create a
complete snippet with all the fields by hand.. and I would to avoid
it.
I was digging for solution in a Lift Book and on group as well, but
without success.
Help!
--~--~-~--~~~---~--~~
You received
[Lift] automaticly generated forms and submit button naming
Hi all,
I've got a following problem. When I create a form form automaticly..
similar to the User login/register example I encontered a problem I'm
not posible to cope with.
Firstly I have 'written' a function (using CopyPaste method) which
creates a form fields list based on my class properties:
private def localForm(place: Place, ignorePassword: Boolean):
NodeSeq = {
signupFields.
map(fi = getSingleton.getActualBaseField(place, fi)).
filter(f = !ignorePassword || (f match {
case f: MappedPassword[Place] = false
case _ = true
})).
flatMap(f =
f.toForm.toList.map(form = plabel{f.displayName}/
label {form}/p) )
}
Next, I wrote some code to return a complete form to the snippet:
def newPlace(place: Place) =
form method=post action={S.uri}
h4Place details/h4
div
{
localForm(place, false)
}
/div
p_WHAT_SHOULD_I_WRITE_HERE_:submit //p
/form
My question is... what do I write in _WHAT_SHOULD_I_WRITE_HERE_ ?
Or better.. how/where to define this value?
In a user login/register example there is submit defined like this:
user:submit
Placing there name of the owner class didn't work.
I know I could use bind but as far as I know next I should create a
complete snippet with all the fields by hand.. and I would to avoid
it.
I was digging for solution in a Lift Book and on group as well, but
without success.
Help!
--~--~-~--~~~---~--~~
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: problems logging
On May 17, 10:33 pm, Timothy Perrett timo...@getintheloop.eu wrote: Can you verify the log4j.xml file is being read? On Mon, May 18, 2009 at 9:38 PM, Channing Walton channingwal...@mac.com wrote: Not sure how I can tell. Specifying -Dlog4j.debug on the command line should prompt log4j to tell you what it's doing. Martin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Why XML tags, not attributes, for lift markup?
Hi, I was wondering why lift markup uses XML elements to reference snippets, rather than using namespaced attributes in the way that (I think) Wicket and Tapestry do? Or like Plone's TAL, which is the first place I saw such a thing. The reason I ask is this: I'm sure I've read somewhere that David P has used these frameworks before (the Java ones, at least)... so it seems most unlikely that such a design was never considered. Perhaps it was just an arbitrary choice? Or was there something more to it than that? I hope this question doesn't sound like criticism - I'm just curious. :o) Martin --~--~-~--~~~---~--~~ 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: Progress on JPADemo and JTA
On Fri, Oct 10, 2008 at 10:37 PM, Derek Chen-Becker [EMAIL PROTECTED] wrote: OK, I think I know how to create a new branch, but being a Git newb I really don't want to nuke anything. Do I just do a git branch my new branch name in my local repo? I think you want: git checkout -b branchName git branch on it's own won't switch to the new branch. Martin --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: expired sessions and log in
On Sun, Oct 5, 2008 at 7:28 PM, Charles F. Munat [EMAIL PROTECTED] wrote: I'm working on an app in which users may spend significant time editing a form before submitting it. It's possible during this time that their session could time out. My concern is that they might submit a long edit, discover that their session has timed out, log in, and lose the edit. (They can probably back up and resubmit, but these are not very savvy users.) I'd like it to remember their update, hold it until they log back in, then send them a prompt to ask if they want to: a) complete the update, b) cancel the update, c) return to the edit form (with their recent edits included, though not yet saved). Any ideas for how to go about this? I guess it's still true that: The best way to deal with the particular situation (browser open, don't want the session to disappear), is to put a hidden CometActor on the page that does nothing other than keep the session alive. - David Pollack http://groups.google.com/group/liftweb/browse_thread/thread/e98f2f75cc4461e4/10a16b586e879b11 Martin --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Caching JPA entities and JPA vs Hibernate
On Tue, Sep 30, 2008 at 11:54 PM, Tim Perrett [EMAIL PROTECTED] wrote: Having an issue with ehcache.xml being picked up. The docs say that it need to be on the classpath - I've tried having it in META-INF, WEB- INF/classes/META-INF but yet nothing seems to work. It never gets picked up...? Where can i stick it so that its forced to be read? IIRC, it needs to be at the top of the classpath, not under META-INF. Martin --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Many to many in Lift mapper
On Sat, Sep 20, 2008 at 10:01 PM, Charles F. Munat [EMAIL PROTECTED] wrote: I can't find any examples of a many-to-many relationship using Lift's mapper. Am I missing one? How does one map two classes in a many-to-many bidirectional relationship? Using the HasManyThrough class: http://liftweb.net/index.php/HowTo_setup_composite_keys Martin --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
