[Lift] Re: [Lift committers] A Groovy welcome to James Strachan who has joined the Lift committers

2010-02-09 Thread James Strachan
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] Re: [Lift committers] A Groovy welcome to James Strachan who has joined the Lift committers

2010-02-08 Thread James Strachan
On 8 February 2010 17:16, David Pollak feeder.of.the.be...@gmail.com wrote:
 Folks,

 I'm wicked pleased that James Strachan has joined the Lift committers.  I'm
 looking forward to the cool stuff that James will add to Lift.

 Please join me in welcoming James!

Thanks David!

Now I just hope I can actually find something interesting to
contribute after that welcome :)

The first thing I was pondering about was a way of easily using
Scalate templates if folks wanted to use, say, Scaml (like a Scala
version of HAML) instead of the usual XML template files in Lift...

http://scalate.fusesource.org/

I know template engines can be like IDEs - very personal things and
I'm totally happy for folks to use whatever template engine/markup
floats their boat - I just figured a bit more choice for lifters might
be a good thing?

-- 
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?

2009-08-13 Thread James Strachan

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-08-13 Thread James Strachan

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-07-30 Thread James Strachan

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-07-30 Thread James Strachan

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?

2009-07-07 Thread James Strachan

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?

2009-07-07 Thread James Strachan

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-06-10 Thread James Strachan

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

2009-05-27 Thread James Strachan

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-05-15 Thread James Strachan

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

2009-05-12 Thread James Strachan

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

2009-04-28 Thread James Strachan

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

2009-04-27 Thread James Strachan

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?

2009-04-22 Thread James Strachan

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-04-22 Thread James Strachan

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-04-22 Thread James Strachan

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-04-22 Thread James Strachan

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

2009-04-17 Thread James Strachan

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
-~--~~~~--~~--~--~---