users@jersey.java.net

Re: [Jersey] using Lift templates with Jersey (was Re: [Jersey] custom TemplateProcessor not having its constructor injected?)

From: James Strachan <james.strachan_at_gmail.com>
Date: Fri, 24 Apr 2009 11:15:48 +0100

2009/4/24 Paul Sandoz <Paul.Sandoz_at_sun.com>:
> On Apr 24, 2009, at 10:19 AM, James Strachan wrote:
>>>>> Is this this the start of a jersey-scala module ? :-)
>>>>
>>>> It could be :). When I've something more interesting than the previous
>>>> bit of code I'll probably pop it up on github first; being neither a
>>>> committer in Jersey or Lift - its then up to other folks to pull it
>>>> into Jersey/Lift as they see fit.
>>>
>>> If you like i can grant you the Developer role for Jersey. I think given
>>> the
>>> patches you have submitted you clearly know what is going on :-)
>>
>> Awesome thanks! :) I'll start hacking up a jersey-scala and
>> jersey-lift module... :)
>>
>
> Great. I will approve your request.

Thanks!


>> Would the contrib's place be the best place to put them?
>>
>
> Yes, would you mind working for the moment in a branch?

Sure, no worries.


> I have just completed the JAX-RS 1.1 integration and we are going to cut a
> stable 1.1.0-ea  (we are calling it "ea" because EE 6 is not final) next
> week.

BTW the jersey-scalar changes are very trivial and low risk (so far
just one implementation of MessageBodyWriter<NodeSeq>) - how about
adding the scala stuff to trunk as they will be ready to release next
week, but keeping the lift stuff (which is gonna take a little while
to get right) to a branch? Being lazy, this would also be a little
easier; as the lift stuff is currently dependent on some hacks to
lift. Happy to do whatever you want though.


> The plan is to then do another release, 1.1.1-ea, just before JavaOne.

Cool


>> I guess we could have jersey-scala as a library, which just provides
>> one or two helpers for using vanilla Scala and JAXRS/Jersey together
>> (e.g. to put the fairly trivial NodeWriter which writes NodeSeq types;
>> so folks can use Scala resource beans like this...
>>
>> @Path("/bar")
>> class BarResource {
>>
>>  @GET
>>  @Produces(Array("text/html"))
>>  def view() = <html><body><h1>Hello World!</h1></body></html>
>> }
>>
>> we could modify the samples/scala-hello-world to reuse the (very
>> trivial) jersey-scala library to show how markup can be created
>> directly in resource beans in scala like above.
>>
>
> Good idea.
>
>
>> We could maybe use Scala Nodes or List/Tuple/Map to create a JSON writer
>> too?
>>
>
> Yes.
>
> I still want to explore this:
>
> http://blogs.sun.com/sandoz/entry/using_scala_s_closures_with

Ah great stuff! I'd missed this post. (I'm now catching up on your
previous scala blog posts... :)

Yeah I'm sure there's loads of ways we can simplify both client side
and server side handling of invariants/entity tags/conditional
processing and so forth with Scala. Am sure pattern matching can be
very helpful too (and on the client side too to conditionally process
if/when results are returned).



>> Then I was thinking there could be a separate jersey-lift library to
>> add lift template support (which would also depend on liftweb). It
>> might be there ends up being a few different template options in the
>> Scala world; there's lifts, then Sweetscala uses freemarker
>> http://code.google.com/p/sweetscala/wiki/MvcView
>>
>> folks might wanna use JSP/Velocity too maybe and maybe there'll be
>> others.
>
> Agreed, it is definitely worth considering a number options here.
>
>
>> I saw a JSP-with-scala like thing the other day but can't find
>> it now.
>>
>
> http://www.nabble.com/-scala-tools--Scala-Server-Pages-td22709066.html

Thats the one! Though I'm personally really liking the lift template
idea; use real Scala code in Scala classes and just bind methods/maps
to tags.

-- 
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/