Paul Sandoz wrote:
>
> 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();
>> }
>>
So the assignments of body parts to parameters would be positional?
Yah, I could see that approach appealing to some users.
>
> 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.
You can experiment with what I've done today in jersey-multipart, on
this topic, by using media type "multipart/x-form-data" (chosen to avoid
clashing with the existing Jersey support for "multipart/form-data"
while we shake things out). The entity will be of type
FormDataMultiPart to allow specialized access to the body parts by field
name.
>
> 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.
>
This should be feasible too.
> Paul.
>
Craig
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>