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 wrote: > For your particular example, you can use head merge as Naftoli suggests. > Head merge is a behavior of Lift templates where any 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 name="foobar" /> and then define what to put there in the surrounded > template using the content > > 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 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: > This site is totally awesome, better than all our > competitors in index.html > Look at all these products in > %%category_name%%in product_list.html > %product_name% - %product_description% > 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. 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 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 wrote: > >> To be parsed by the bind, it must be enclosed by >> ... >> >> 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
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 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: This site is totally awesome, better than all our competitors in index.html Look at all these products in %%category_name%%in product_list.html %product_name% - %product_description% 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. 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 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 wrote: > To be parsed by the bind, it must be enclosed by > ... > > 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: > > > > class HelloWorld { > >def meta_desc(ns: NodeSeq): NodeSeq = Text("test desc") > > } > > Which will result in this XHTML: > > test desc > > Or, if you want to keep it in the hello method, you'd then have to move the > to the outside of the template: > > > ... > > > >... > > > > 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 > > > > > > 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
[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 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.
[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 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 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 " 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
On Thu, Jan 21, 2010 at 8:37 PM, David Pollak 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 > wrote: >> >> On Thu, Jan 21, 2010 at 8:31 PM, David Pollak >> 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] RC8 candidate for the first 2.8.0 beta
On Thu, Jan 21, 2010 at 8:31 PM, David Pollak 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
(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.
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 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: > > - 2.8.0.Beta1-RC3 > + 2.8.0.Beta1-RC5 > > 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.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On Tue, Dec 22, 2009 at 6:48 PM, martin odersky wrote: > I found someone who could download the repository with git. So trying > again now. ... and it builds with RC3. Great! So now I have something to work with ... 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.
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 wrote: > On Tue, Dec 22, 2009 at 6:24 PM, Indrajit Raychaudhuri > wrote: >> >> On 22/12/09 10:44 PM, martin odersky wrote: >>> >>> On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri >>> wrote: >>>> >>>> Martin, >>>> >>>> I think the jetty version is incorrect in the pom.xml in test:sample. >>>> >>>> It should be: >>>> >>>> org.mortbay.jetty >>>> jetty >>>> [6.1.6,7.0) >>>> >>> ... 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. >> >> >> lift-base >> lift-persistence >> lift-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 6:24 PM, Indrajit Raychaudhuri wrote: > > On 22/12/09 10:44 PM, martin odersky wrote: >> >> On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri >> wrote: >>> >>> Martin, >>> >>> I think the jetty version is incorrect in the pom.xml in test:sample. >>> >>> It should be: >>> >>> org.mortbay.jetty >>> jetty >>> [6.1.6,7.0) >>> >> ... 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. > > > lift-base > lift-persistence > lift-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 6:09 PM, Indrajit Raychaudhuri wrote: > Martin, > > I think the jetty version is incorrect in the pom.xml in test:sample. > > It should be: > > org.mortbay.jetty > jetty > [6.1.6,7.0) > ... 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:09 PM, Indrajit Raychaudhuri wrote: > Martin, > > I think the jetty version is incorrect in the pom.xml in test:sample. > > It should be: > > org.mortbay.jetty > jetty > [6.1.6,7.0) > > 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
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
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/12
[Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On Tue, Dec 22, 2009 at 3:41 PM, Heiko Seeberger 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 > -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.
[Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On Tue, Dec 22, 2009 at 2:35 PM, Josh Suereth 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 2:01 PM, Josh Suereth 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] RC4 candidate for the first 2.8.0 beta
On Sun, Dec 20, 2009 at 12:39 PM, martin odersky 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 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
[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" 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 > Date: Sat, 14 Nov 2009 16:32:19 > To: Lift > 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] 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 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 wrote: > It sounds like you probably want { SHtml.submit("Title of submit > button", () => actionToTakeWhenButtonIsUsedToSubmitForm) } > > 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: > > > Place details > > > > > > > > > > > > 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 Copy&Paste 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 => {f.displayName} > label> {form}) ) > > } > > > Next, I wrote some code to return a complete form to the snippet: > > > def newPlace(place: Place) = > > > > Place details > > > > { > > localForm(place, false) > > } > > > > <_WHAT_SHOULD_I_WRITE_HERE_:s
[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 Copy&Paste 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 => {f.displayName} {form}) ) } Next, I wrote some code to return a complete form to the snippet: def newPlace(place: Place) = Place details { localForm(place, false) } <_WHAT_SHOULD_I_WRITE_HERE_:submit /> 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: 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: New Lift Actor code
On Sat, May 23, 2009 at 6:19 AM, David Pollak wrote: > I am happy to share the Lift Actor code with EPFL and if it makes it into > the Scala distribution as SimpleActors or something similar, I'm totally > cool with that. I'm not interested in owning or maintaining an Actor > library. I am however, dedicated to making sure that Lift apps can run in > production for months (or even years) without retaining memory or having > other problems that can impact the stability of applications. The cool thing about this is that it provides solid evidence that Scala - as a language - does satisfy the aim of being be a scalable language. I'm referring to the fact that Scala actors are not part of the core language. They're just a library that can be replaced with a different library, which can also to provide the 'feel' of native language support for objects of that type. It's such a fundamental part of the language design that Programming in Scala talks about it in Chapter 1, Section 1. It's timely that you sent the email so soon after the link to the Guy Steele "Growing a Language" OOPSLA presentation (of which I am still in awe) went around on twitter. http://video.google.com/videoplay?docid=-8860158196198824415 I guess this demonstrates that Scala provides the features for growth that Steele says are needed for languages to be successful in the long term, and that he would have liked Java to have. Awesome. Nice, clear explanation, by the way. Should avoid any any NIH allegations on the diggs and reddits of the world ;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] 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: problems logging
> On May 17, 10:33 pm, Timothy Perrett wrote: >> Can you verify the log4j.xml file is being read? >> On Mon, May 18, 2009 at 9:38 PM, Channing Walton 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] 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 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 -~--~~~~--~~--~--~---
[Lift] Re: One further: JPA + JTA + Lift
On Wed, Sep 10, 2008 at 4:27 PM, Kris Nuttycombe <[EMAIL PROTECTED]> wrote: > The only question I have is thread safety - it doesn't seem > like I should really be using a variable on the singleton to store the > transaction; should I instead be creating a separate RequestVar to > hold it? It is thread safe to use a singleton - in fact, it's what Sun do in the code that accompanies the Java EE Tutorial... web/books/src/main/java/com/sun/books/listeners/ContextListener.java: public final class ContextListener implements ServletContextListener { @PersistenceUnit private EntityManagerFactory emf; private ServletContext context = null; @Resource private UserTransaction utx; public void contextInitialized(ServletContextEvent event) { context = event.getServletContext(); try { context.setAttribute("emf", emf); Globals.UTX = utx; ... where Globals is defined as: public class Globals { public static UserTransaction UTX; } Hence, using val instead of def should be fine. The begin() and commit() javadoc on UserTransaction: "Create a new transaction and associate it with the current thread." "Complete the transaction associated with the current thread. When this method completes, the thread is no longer associated with a transaction." The transaction is associated with the thread that called begin() 'internally', so there's no need to associate it with a thread manually. See also: http://java.sun.com/javaee/5/docs/tutorial/doc/bnafo.html 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: JPA w/Scala
Hi Tim, On Mon, Sep 8, 2008 at 12:29 PM, Tim Perrett wrote: > > Just been doing some more debugging on this - it appears that the > correct values are being passed through and are assigned to an entity > instance, but they blow up when trying to do the em.merge(author) > call. > > The stack trace I get is: You didn't post the full stack trace (or at least, it didn't show up in gmail), but there are only two places I can see merge being called: (Authors) def add (xhtml : NodeSeq) : NodeSeq = { def doAdd () = { if (author.name.length == 0) { error("emptyAuthor", "The author's name cannot be blank") } else { Model.merge(author) redirectTo("list.html") } } and (Books) def add (xhtml : NodeSeq) : NodeSeq = { def doAdd () = { Model.merge(book) redirectTo("list.html") } The above looks slightly fishy, but I'm afraid I don't have time right now to try the project to check. If you want to add something, shouldn't you be calling persist rather than merge? I'd expect to see merge being used in a method called doUpdate() or whatever... ... or can you really get away with calling merge when something's not in the DB yet? Just a thought. Regards Martin > > ### AUTHOR > [EMAIL PROTECTED] > ### AUTHOR ID > 0 > ### AUTHOR NAME > sdfsdssdfs > DEBUG - opened session at timestamp: 12208732519 > DEBUG - begin > DEBUG - opening JDBC connection > DEBUG - total checked-out connections: 0 > DEBUG - using pooled JDBC connection, pool size: 0 > DEBUG - current autocommit status: true > DEBUG - disabling autocommit > DEBUG - after transaction begin > DEBUG - id unsaved-value: 0 > DEBUG - transient instance of: com.foo.jpaweb.model.Author > DEBUG - merging transient instance > DEBUG - saving [com.foo.jpaweb.model.Author#] > DEBUG - executing insertions > DEBUG - Wrapped collection in role: com.foo.jpaweb.model.Author.books > DEBUG - executing identity-insert immediately > DEBUG - Inserting entity: com.foo.jpaweb.model.Author (native id) > DEBUG - about to open PreparedStatement (open PreparedStatements: 0, > globally: 0) > DEBUG - insert into authors (name, id) values (?, ?) > Hibernate: insert into authors (name, id) values (?, ?) > DEBUG - preparing statement > DEBUG - Dehydrating entity: [com.foo.jpaweb.model.Author#] > DEBUG - binding 'sdfsdssdfs' to parameter: 1 > DEBUG - about to close PreparedStatement (open PreparedStatements: 1, > globally: 1) > DEBUG - closing statement > DEBUG - could not insert: [com.foo.jpaweb.model.Author] [insert into > authors (name, id) values (?, ?)] > java.sql.SQLException: Parameter #2 has not been set. >at > net.sourceforge.jtds.jdbc.ConnectionJDBC2.prepareSQL(ConnectionJDBC2.java: > 613) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---