[Lift] Re: [Lift committers] A Groovy welcome to James Strachan who has joined the Lift committers
Just bringing this thread that drifted off onto the committers list back here... On 8 February 2010 18:58, Naftoli Gugenheim naftoli...@gmail.com wrote: Welcome! Out of curiosity, what are the advantages of this other templating engine? Probably the Haml site describes it quite well (see the showdown at the bottom)... http://haml-lang.com/ basically its a very concise way of making markup - though its a different kind of templating engine to the one in lift where there is no code at all in a template and you bind via reflection XML elements to functions which then replace elements with values or apply other transformations etc. I've used lots of different template engines over the years; they seem to all have strengths and weaknesses - it mostly depends on what the make up skills of the team is how the team work with web designers etc. If I'm on a project where I don't have to chuck templates over a wall to be edited by a web designer I find the Scaml approach a little easier on my brain fingers with the cost that there's no IDE to render it other than the actual web browser and there's code in the template which can be viewed as a bad thing - YMMV though. -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ -- 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] any idea when we can cut a 1.1-M5 release?
Now that the APIs have changed to abstract the servlet stuff, I'd really like a 1.1-M5 release. Anyone any objections to cutting one soon? -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: any idea when we can cut a 1.1-M5 release?
2009/8/13 Timothy Perrett timo...@getintheloop.eu: To what end? Not a lot of code has gone in since the 1.1-m4 I just wanna be able to use the new APIs (which avoid the explicit use of servlets) without being on the bleeding edge. e.g. S.render() changed to not take HttpServletRequest. -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Jersey + Lift, whats the story?
2009/7/17 Timothy Perrett timo...@getintheloop.eu: Hey guys, I've been taking a look at Jersey and how it operates with Lift by way of the recent integration that cropped up on dev.java.net... Though it did start here first! :) http://www.nabble.com/using-Lift-templates-stand-alone-inside-other-frameworks-like-JAXRS--td23177478.html#a23558689 BTW it was only when there was lukewarm response on the fork I created at github that I popped it into Jersey instead. Though David did most of the heavy lifting hacking Lift to make templates reusable outside of Lift's normal servlet+controller layer From my perspective, I see how having a standard RS service framework could be helpful, but it appears to bypass important lift concepts like SiteMap etc so I'm just wondering what the benefit of using such a layer would be over using DispatchPF etc to create REST services or serving xml fragments for templates? (I have no idea about Jersey apart from the basic docs ive read, so if im missing a major benefit id love to hear discuss) As David said there are strengths and weaknesses to both approaches. I see them as alternatives really; use one approach or the other or mix them if required. My main motivation of the original Jersey - Lift integration was to enable JAXRS folks to reuse Scala/Lift code for templating instead of the joy that is JSP/JSP EL/JSTL/custom tag files/(SiteMesh|Tiles). I'd always assumed the SiteMap and JAXRS were kinda separate parts of the URI space. Though having said that I've just noticed that using Jersey + Lift trunk together in an application is currently broken unless there is some kind of SiteMap defined :). I wonder if one day we can kinda get Jersey to expose its own SiteMap (of sorts) into Lift's SiteMap? -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Jersey + Lift, whats the story?
2009/7/30 James Strachan james.strac...@gmail.com: 2009/7/17 Timothy Perrett timo...@getintheloop.eu: Hey guys, I've been taking a look at Jersey and how it operates with Lift by way of the recent integration that cropped up on dev.java.net... Though it did start here first! :) http://www.nabble.com/using-Lift-templates-stand-alone-inside-other-frameworks-like-JAXRS--td23177478.html#a23558689 BTW it was only when there was lukewarm response on the fork I created at github that I popped it into Jersey instead. Though David did most of the heavy lifting hacking Lift to make templates reusable outside of Lift's normal servlet+controller layer From my perspective, I see how having a standard RS service framework could be helpful, but it appears to bypass important lift concepts like SiteMap etc so I'm just wondering what the benefit of using such a layer would be over using DispatchPF etc to create REST services or serving xml fragments for templates? (I have no idea about Jersey apart from the basic docs ive read, so if im missing a major benefit id love to hear discuss) As David said there are strengths and weaknesses to both approaches. I see them as alternatives really; use one approach or the other or mix them if required. My main motivation of the original Jersey - Lift integration was to enable JAXRS folks to reuse Scala/Lift code for templating instead of the joy that is JSP/JSP EL/JSTL/custom tag files/(SiteMesh|Tiles). I'd always assumed the SiteMap and JAXRS were kinda separate parts of the URI space. Though having said that I've just noticed that using Jersey + Lift trunk together in an application is currently broken unless there is some kind of SiteMap defined :). Strike that - pilot error! I'd broken the web.xml in that application to disable Jersey's filter, DOH :). Jersey + Lift works fine with 1.1-SNAPSHOT and 1.1-M3 of Lift. I wonder if one day we can kinda get Jersey to expose its own SiteMap (of sorts) into Lift's SiteMap? It would certainly be useful to reuse Lift's Menu rendering when using a Lift template to render a JAXRS resource bean; am sure that would not be too hard to fix. We might want to support adding resource beans to the menus too -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] mirroring the lift mailing list to nabble?
Just an idle thought. I wonder if folks wanted to mirror the mailing list to nabble? I mused on twitter today about the relative activity of the various programming languages on nabble... http://www.nabble.com/Programming-Languages-f13993.html then Graham Rocher spotted that Ruby also included Rails in its total; it turns out Python includes Django and PHP includes Zend CakePHP (though Groovy doesn't include Grails yet). so I thought it might be interesting to get a vague feel of relative community activity sizes if we added Lift as a group on nabble and added it to the Scala and Web Development Framework sub groups http://www.nabble.com/Web-Development-Framework-f16257.html http://www.nabble.com/Scala-Programming-Language-f20934.html Its pretty easy to sign up, IIRC you should be a list maintainer though. No biggie though! :) -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: mirroring the lift mailing list to nabble?
DOH! Didn't' think to search for liftweb! Its already there... http://www.nabble.com/liftweb-f30586.html its just not in any categories. Whoever's admin, fancy adding it to Scala Web Development Frameworks? 2009/7/7 James Strachan james.strac...@gmail.com: Just an idle thought. I wonder if folks wanted to mirror the mailing list to nabble? I mused on twitter today about the relative activity of the various programming languages on nabble... http://www.nabble.com/Programming-Languages-f13993.html then Graham Rocher spotted that Ruby also included Rails in its total; it turns out Python includes Django and PHP includes Zend CakePHP (though Groovy doesn't include Grails yet). so I thought it might be interesting to get a vague feel of relative community activity sizes if we added Lift as a group on nabble and added it to the Scala and Web Development Framework sub groups http://www.nabble.com/Web-Development-Framework-f16257.html http://www.nabble.com/Scala-Programming-Language-f20934.html Its pretty easy to sign up, IIRC you should be a list maintainer though. No biggie though! :) -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: JTA Transaction Monad - Early Access Program
2009/6/9 Jonas Bonér jbo...@gmail.com: 2009/6/9 David Pollak feeder.of.the.be...@gmail.com: Jonas, We always use Maven to load dependencies. We never use GPL dependencies. If you have a question about the license of a dependency and its use in Lift, please ping me privately. I am using Maven. But as I said I could not find the Atomikos in any public library, putting them in lib will let the user easily install them in their local repo. Do you know if they are in any public repo? If its any help I added them here a while back for an integration test in ActiveMQ http://repo.fusesource.com/maven2-all/com/atomikos/ the repo is: http://repo.fusesource.com/maven2-all/ you might wanna put more recent jars up on some public repo though. -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Session usage in Lift
If you were building an application which didn't require any COMET nor needed any data stored in the session and you were happy to disable the random form field name generation (so a form submission, due to failover/load balancing could be processed by any servlet container in the cluster) - would Lift still work in failover scenarios or would it totally barf? I understand that generating random names for things can be troublesome (I can imagine the callbacks used in forms having similar problems) - are there other bits of Lift that could cause issues? I'm just wondering if Lift can ever be used in a share-nothing kinda deployment, or if session replication is mandatory. 2009/5/27 marius d. marius.dan...@gmail.com: On May 27, 9:17 am, Kristinn kristinn.daniels...@gmail.com wrote: Yes, I understand your confusion, however sometimes people make designs that don't make much sense to others on first look (like using sessions for rendering all html). But there are often good reasons for these decisions (admittedly often these decisions are just bad). In our case we only need the user id for each request, we wouldn't have needed to store anything else in the session. So if we use cookie to do the authentication, we don't need session replication nor sticky loadbalancing. Therefore we have very efficient load balancing, fail- over, and zero-downtime-deployments. You can take out any instance at anytime without the user noticing a thing. Sorry, this sounds like I'm trying to defend the design, I wasn't going to do that. btw. Why is the session used for rendering the html? Lift (like so many other frameworks) request processing rendering phase happens in a stateful context meaning that it allows you out of the box to maintain state between requests. In this way you can seamlessly add COMET support a many other features without worrying about state etc. Also for Lift the users bound functions must be kept per session in order to work. So rendering markup is not as simple as it may appear as lots of things are correlated to that. if you have a completely static markup (plain HTML) then this markup should probably be served by a front-end static content. On May 26, 10:44 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, May 26, 2009 at 1:26 PM, Kristinn kristinn.daniels...@gmail.comwrote: Thanks for your answer. I'm not sure what you'd like to know about the app. It's an internal project, task and idea management application, written in Java using the Stripes web framework, and Apache Lucene for persistence. We use a cookie to authenticate the user, this is done on each request. So do you have content and access control that is specific to each use, but you're just not using the Servlet container's session mechanism? Sorry for being confused. Is there anything in particular that you would like to know? On May 26, 10:00 pm, David Pollak feeder.of.the.be...@gmail.com wrote: At this point, Lift requires sessions for all HTML rendering. It might be possible to do something such that all the various requests share the same session and there's no JSESSIONID and no need for stickiness. Can you tell us a little more about your app? On Tue, May 26, 2009 at 12:07 PM, Kristinn kristinn.daniels...@gmail.comwrote: Hi, I'm looking into migrating an existing application to Lift. This application does not use sessions at all, and we do load balancing without session stickiness. Now my question is: does Lift for some reason require sessions on it's own? Or, would we have to switch to load balancing with session stickiness? Thanks, Kristinn -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: using Lift templates stand alone inside other frameworks like JAXRS?
2009/5/14 David Pollak feeder.of.the.be...@gmail.com: On Thu, May 14, 2009 at 12:55 AM, James Strachan james.strac...@gmail.com wrote: 2009/5/13 David Pollak feeder.of.the.be...@gmail.com: Please see: S.render(NodeSeq, HttpServletRequest): NodeSeq Awesome - huge thanks! :) I was just about to post a patch I'd figured out to implement this in a way less elegant way; you saved me the trouble :) I've managed to use this API to provide a basic integration of Lift templates and Jersey http://github.com/jstrachan/liftweb/tree/master/lift-jersey I'm still working on it to provide some better examples (and navigation isn't quite working yet), but so far its working pretty well! Cool. Are you involved with Dan Kulp in your JAXRS work? I work with Dan and know him well; but I hack on Jersey - I don't work on CXF. -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: OSGi support for Lift
BTW speaking of PAX - I've found a nice easy way to test OSGI jars (as its so easy to mess up the metadata) is to use Pax Exam to create an OSGi integration test of your bundles against one or more OSGi containers (e.g. Felix and Equinox), using the maven poms and the Apache ServiceMix/Karaf plugin to deduce the versions of the dependencies you're using to avoid hard coding them in your integration test. More details here: http://macstrac.blogspot.com/2009/04/if-you-are-using-osgi-then-give-pax.html 2009/5/12 Alex Boisvert boisv...@intalio.com: Hi Heiko, Just a few basic questions I downloaded and ran PAX runner, ./pax-run.sh --profiles=log,scala,felix.webconsole,web then installed the examples-osgi bundle, - install file:///home/boisvert/git/liftweb/sites/examples-osgi/hello/target/examples-osgi-hello-1.1-SNAPSHOT.jar Bundle ID: 9 - [FelixDispatchQueue] DEBUG net.liftweb.examples-osgi-hello - BundleEvent INSTALLED start 9 - [FelixDispatchQueue] DEBUG net.liftweb.examples-osgi-hello - BundleEvent RESOLVED [FelixDispatchQueue] DEBUG net.liftweb.examples-osgi-hello - BundleEvent STARTED Now how to I access the Lift app? How does the servlet context get mapped onto Jetty? It is normal there's no web.xml in this project? (I can access the Felix admin console at http://localhost:8080/system/console) alex -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] [patch] work around for errors running unit tests in IDEA/NetBeans
I was trying out various IDEs to run the unit tests in the lift-webkit module and was getting errors. I guess due to recent changes in scala language version? Here's the trivial patch that fixes it - it seems reflection on the continuation stuff was no longer working http://github.com/jstrachan/liftweb/commit/2ca3b683733969bd8689e36dad99a990711b4071 -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Feedback on screen cast, please
Great stuff! The only thing I can think of that could be improved is maybe mentioning the JavaRebel stuff; when seeing Rails demos, there's no stop-start-wait-30 seconds type stuff while maven does its thing - maybe in the next screen cast the JavaRebel stuff could be shown so that the same rails-ish RADness is possible. 2009/4/25 David Pollak feeder.of.the.be...@gmail.com: I've posted it at blip.tv: http://liftweb.blip.tv It seems to have good audio synchronization. On Sat, Apr 25, 2009 at 6:04 AM, Derek Chen-Becker dchenbec...@gmail.com wrote: Hmmm. VLC on Linux worked fine viewing it for me. Derek On Fri, Apr 24, 2009 at 11:11 PM, Warren Henning warren.henn...@gmail.com wrote: On Fri, Apr 24, 2009 at 8:50 AM, David Pollak feeder.of.the.be...@gmail.com wrote: I'd like to get some critical feedback on it so I can improve it. I'm short on criticism - this was really cool. You might want to comment on how much compile time there is when you're rapidly updating a Lift application so people don't think you spend half your development time waiting for the computer or something. I'd like to note that for some reason when I opened the machine on my default media viewer, the video didn't work right although audio was fine - VLC 0.8.6e, Windows XP SP2. Opening in QuickTime worked fine though. Warren -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] using Lift templates stand alone inside other frameworks like JAXRS?
This might seem a truly bizarre request - particularly to folks who
solely use lift as their web framework; but I've been hacking up a
number of JAXRS services - I'm a big JAXRS fan (and slowly being drawn
to scala/lift).
I'd like to make Lift templates an option for any JAXRS developer
who's made a RESTful service and wants nice HTML/XML/Atom views using
Lift snippets etc. A thread recently started on the Jersey list btw...
http://n2.nabble.com/using-Lift-templates-with-Jersey-%28was-Re%3A--Jersey--custom--TemplateProcessor-not-having-its-constructor-injected-%29-td2675518.html
I've started hacking up a Jersey TemplateProcessor to wire in Lift
templates using implicit views; I can grab the template using Lift's
TemplateFinder fine - but I've just not got enough Lift implementation
knowledge yet to figure out how to render it :). I tried using
LiftServlet but thats a bit of a hack and it tends to just return the
template itself (since I'm not using Lifts mapping of URIs to requests
etc) - I kinda need to go in somewhere in between the two :)
FWIW I'm imagining two possible options
(i) folks write Java Resource Beans for JAXRS then wire Lift templates
using the @ImplictProvides mechanism to hook a resource bean to the
Lift template
(ii) folks create markup - or template instantiations within their
JAXRS beans written in Scala then there's no need for the
@ImplicitProvides hook. e.g.
@Path(/bar)
class MyResource {
@GET
@Produces(Array(text/html))
def view() = htmlbodyh1Hello World!/h1/body/html
...
@POST
def foo(form: SomeBean) = {...}
}
In either case, I need some little hook to be able to take a
Box[NodeSeq] and pass it to Lift to render it using the standard lift
tags + snippets etc.
This could be a gentle way to get folks gradually hooked on
Scala/Lift; gradually moving from Java/JSP to Scala/Lift for
templates, then resource beans etc. (Changing web frameworks is often
a big decision to make, though switching out JSP and using Lift
templates is a kinda no brainer... :)
I wondered if any Lift ninja's could give me some hints at a clean way
to do this?
--
James
---
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: getting mvn jetty:run to reload changes to snippets
2009/4/17 David Pollak feeder.of.the.be...@gmail.com: On Fri, Apr 17, 2009 at 10:00 AM, James Strachan james.strac...@gmail.com wrote: Hello Lifters! BTW apologies in advance if this is an obvious newbie question - I did a fair bit of searching on the list and saw JavaRebel discussions etc. I've been taking my first baby steps with Scala/Lift (this Scala/Lift malarkey is starting to grow on me) so I followed the getting started guide. My first surprise (after using Rails/JSP etc) was hitting reload on a browser after changing a snippet doesn't reload the snippet code - you've gotta stop/restart mvn jetty:run. (Though changing the template does). I just wondered if someone had figured out the ninja to get the jetty:run plugin to auto-detect snippet changes? This could well be a tooling issue (e.g. when using eclipse with its incremental compiling generating new class files might solve the problem) - I'm using IDEA currently. I did wonder if we could come up with a way to configure the jetty:run plugin to do the right thing though irrespective of your IDE; using the scala incremental compiler maybe? I tried adding a jetty custom scan target to the pom... plugin groupIdorg.mortbay.jetty/groupId artifactIdmaven-jetty-plugin/artifactId configuration contextPath//contextPath scanIntervalSeconds1/scanIntervalSeconds scanTargetPatterns scanTargetPattern directorysrc/main/scala/directory includes include**/*.scala/include /includes /scanTargetPattern /scanTargetPatterns /configuration /plugin which forces a restart fine - but it doesn't know to recompile the Scala code. So I'm wondering if we setup the scala compiler to auto build the code to a classes directory that the jetty plugin can then auto-detect and restart the web app? This command line will keep the class files up to date. Using JavaRebel is better than having Jetty reload the classes and Jetty will destroy sessions on reload. mvn scala:cc Many thanks, that worked a treat. For those following this thread; the instructions here worked a treat... http://wiki.liftweb.net/index.php?title=JavaRebel in one shell I run mvn jetty:run then in another I run mvn scala:cc and it works like a charm! -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: using Lift templates stand alone inside other frameworks like JAXRS?
2009/4/22 David Pollak feeder.of.the.be...@gmail.com: James, This is an interesting idea that more than one person has expressed excitement about. Jorge Ortiz (one of the Lift committers) was puttering around with the separation of Lift's templating from the rest of Lift. Personally, I think it's a pretty daunting task because a lot of the ways that Lift looks for templates and does its wiring and looks for snippets and generally re-writes the XML (e.g., to insert the Comet JavaScript), is woven tightly with the rest of Lift (e.g., LiftRules, LiftSession, etc.) I am in favor of something like this happening, but I really think it's non-trivial. Perhaps... just perhaps... we could do something where we put Java wrappers around some of the Lift-isms and use Lift as Filter in Java apps. If you'd care to fork the Lift repository on GitHub and recruit a few others to help you, this could be an interesting side-project that, if successful, I could see as part of the main Lift distribution. Cool thanks. BTW I don't much mind about ripping the template stuff out of Lift into a separate piece - I am totally happy to have LiftRules/LiftSession, Comet et al there and to keep Lift intact. I guess all I really want is a way to render a NodeSeq which can contain lift:surround and other arbitrary snippets inside. So all I really want is another entry point into Lift other than the filter/servlet where somehow I can do something like this... LiftServlet.render(xhtml:NodeSeq, out:OutputStream) which delves into the internal Lift stuff I don't grok in between LiftServlet and TemplateFinder and does all that cool magic :) I could pass in a servletRequest/response too if that'd help make the implementation easier. I realise this could be tricky though with all that ajax stuff etc. -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: using Lift templates stand alone inside other frameworks like JAXRS?
2009/4/22 David Pollak feeder.of.the.be...@gmail.com: On Wed, Apr 22, 2009 at 9:16 AM, James Strachan james.strac...@gmail.com wrote: 2009/4/22 David Pollak feeder.of.the.be...@gmail.com: James, This is an interesting idea that more than one person has expressed excitement about. Jorge Ortiz (one of the Lift committers) was puttering around with the separation of Lift's templating from the rest of Lift. Personally, I think it's a pretty daunting task because a lot of the ways that Lift looks for templates and does its wiring and looks for snippets and generally re-writes the XML (e.g., to insert the Comet JavaScript), is woven tightly with the rest of Lift (e.g., LiftRules, LiftSession, etc.) I am in favor of something like this happening, but I really think it's non-trivial. Perhaps... just perhaps... we could do something where we put Java wrappers around some of the Lift-isms and use Lift as Filter in Java apps. If you'd care to fork the Lift repository on GitHub and recruit a few others to help you, this could be an interesting side-project that, if successful, I could see as part of the main Lift distribution. Cool thanks. BTW I don't much mind about ripping the template stuff out of Lift into a separate piece - I am totally happy to have LiftRules/LiftSession, Comet et al there and to keep Lift intact. I guess all I really want is a way to render a NodeSeq which can contain lift:surround and other arbitrary snippets inside. So all I really want is another entry point into Lift other than the filter/servlet where somehow I can do something like this... LiftServlet.render(xhtml:NodeSeq, out:OutputStream) Would: LiftServlet.render(xhtml:NodeSeq, httpRequest: HttpServletRequest): LiftResponse work along with helper methods to stream a LiftResponse out to an OutputStream work? That would be perfect, yes please! :) -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] getting mvn jetty:run to reload changes to snippets
Hello Lifters! BTW apologies in advance if this is an obvious newbie question - I did a fair bit of searching on the list and saw JavaRebel discussions etc. I've been taking my first baby steps with Scala/Lift (this Scala/Lift malarkey is starting to grow on me) so I followed the getting started guide. My first surprise (after using Rails/JSP etc) was hitting reload on a browser after changing a snippet doesn't reload the snippet code - you've gotta stop/restart mvn jetty:run. (Though changing the template does). I just wondered if someone had figured out the ninja to get the jetty:run plugin to auto-detect snippet changes? This could well be a tooling issue (e.g. when using eclipse with its incremental compiling generating new class files might solve the problem) - I'm using IDEA currently. I did wonder if we could come up with a way to configure the jetty:run plugin to do the right thing though irrespective of your IDE; using the scala incremental compiler maybe? I tried adding a jetty custom scan target to the pom... plugin groupIdorg.mortbay.jetty/groupId artifactIdmaven-jetty-plugin/artifactId configuration contextPath//contextPath scanIntervalSeconds1/scanIntervalSeconds scanTargetPatterns scanTargetPattern directorysrc/main/scala/directory includes include**/*.scala/include /includes /scanTargetPattern /scanTargetPatterns /configuration /plugin which forces a restart fine - but it doesn't know to recompile the Scala code. So I'm wondering if we setup the scala compiler to auto build the code to a classes directory that the jetty plugin can then auto-detect and restart the web app? I just wondered if others had hit this issue come up with an elegant solution; to force incremental compilation of the Scala class files - or maybe I should just switch to eclipse? -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
