Besides binding, we still need conversion and validation to use jersey
as the main framework. Perhaps it would be possible reuse struts 2
conversion and validation (the current best, IHMO), or even make this
"pluggable".
On Tue, Jan 27, 2009 at 3:22 PM, James Strachan
<james.strachan_at_gmail.com> wrote:
> 2009/1/27 Paul Sandoz <Paul.Sandoz_at_sun.com>:
>>
>> On Jan 27, 2009, at 5:33 PM, James Strachan wrote:
>>
>>> 2009/1/27 Craig McClanahan <Craig.McClanahan_at_sun.com>:
>>>>
>>>> James Strachan wrote:
>>>>>
>>>>> I've been pondering this for a little while; is JAX-RS the kinda long
>>>>> term replacement for all the zillions of web frameworks out there?
>>>>>
>>>>> I tend to think, yes it mostly is for most requirements - and we're
>>>>> nearly there, just a few things to fix up and improve. I've just
>>>>> blogged (a rather long post for me) about it, brain dumping my
>>>>> thoughts
>>>>>
>>>>>
>>>>> http://macstrac.blogspot.com/2009/01/jax-rs-as-one-web-framework-to-rule.html
>>>>>
>>>>> it could well feed the trolls but it'd be interesting to hear if
>>>>> others have been having similar thoughts (or maybe I'm just smoking
>>>>> crack :).
>>>>
>>>> Having seen you party, I'm not sure I could tell the difference ... :-)
>>>
>>> LOL! Hi Craig, long time no see! I nearly referred to you in that blog
>>> post using Hani's McClanahanahanahan but couldn't remember the correct
>>> spelling & repetition :)
>>>
>>>
>>>>> From seeing folks hit similar issues to me in the implicit
>>>>> views / static files /JSP mappings areas - it looks like at least a
>>>>> few folks are trying to do similar things.
>>>>>
>>>>
>>>> Perhaps ironically (given my background), I haven't paid a lot of
>>>> attention
>>>> to using Jersey for a webapp that produces server side HTML views.
>>>> That's
>>>> probably because nearly all my time nowdays is going towards REST
>>>> services
>>>> based Jersey, with a heavy dose of Jersey Client for the Java clients
>>>> (although I'm using Ruby/Python/PHP for that as well). But I think
>>>> there's
>>>> a lot of merit in your comments here.
>>>>
>>>> The biggest single issue (to me) is one you mentioned, and it's not just
>>>> a
>>>> JAX-RS issue. It's the problem of letting the container do its thing for
>>>> static resources. You can work around this by ugly things like different
>>>> context paths for the resources and the static files (or explicitly map
>>>> every root resource "foo" to path "/foo/*" and remember to update when
>>>> you
>>>> add a new root resource), but it would really be nice if Servlet 3.0 let
>>>> us
>>>> do a more sophisticated mapping job.
>>>
>>> Agreed!
>>>
>>>
>>>> PS: Thanks for the props on jersey-multipart. What kind of thing did
>>>> you
>>>> have in mind for "direct binding with any bean"?
>>>
>>> I was just mentally joining the dots (without being very clear)
>>> between stuff you'd posted on the multipart thread; where you could
>>> bind directly to parameters to avoid using an explicit MultPart type
>>>
>>> e.g.
>>>
>>> @Path("...")
>>> @PUT
>>> @Consumes("multipart/mixed")
>>> @Produces(...)
>>> public void handler(String text, MyBean bean) {...}
>>>
>>> instead of
>>>
>>> public void handler(MultiPart multipart) {..
>>> BodyPart part0 = multiPart.getBodyParts().get(0);
>>> String text = part0.getEntityAs(String.class);
>>> BodyPart part1 = multiPart.getBodyParts().get(1);
>>> MyBean bean = part1.getEntityAs(MyBean.class);
>>> ...
>>> multiPart.cleanup();
>>> }
>>>
>>
>> You can do that with @FormParam for multipart/form-data, the name of the
>> form parameter corresponds to the name in the content disposition header.
>> Craig has been working on transitioning over the implementation of that to
>> build upon the multipart API.
>>
>> I would like to see beans being used, say:
>>
>> @Multipart
>> public class MultipartBean {
>> // possible annotations on bean properties.
>> String text;
>> MyBean bean;
>> }
>>
>> @POST
>> public void post(MultipartBean bean) { ... }
>>
>> same applies to form parameter beans.
>
> Thats neat! :)
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>