Hi Julio,
I think perhaps the best place to look at first is 3 because there is
less dependencies. Some of the techniques that may be used to map such
things to beans could be then applied to 4.
The form parameters are stored in an instance of Form, which just
extends MultivaluedMap<String, String>, and can be obtained from:
com.sun.jersey.api.core.HttpRequestContext#getFormParameters()
So you could experiment with mapping keys and values in a
MultivaluedMap to a Java Bean. IIRC Craig had some suggestions on what
to use here. Some things to consider:
- multiple values;
- default values, reuse @DefaultValue ? ;
- conversion of String to type, reuse rules for @FormParam ?.
- bean validation?
Paul.
On Nov 7, 2008, at 1:37 PM, Julio Faerman wrote:
> Yes, i would like to contribute.
> But i am currently a jersey user, have never touched the code, so it
> would take me some delay to get started. If you (or other) could
> suggest some starting pointers, it would help a lot.
>
> On Fri, Nov 7, 2008 at 7:45 AM, Paul Sandoz <Paul.Sandoz_at_sun.com>
> wrote:
>> Hi,
>> Julio, in a previous email you expressed interest in contributing
>> in this
>> area. Would you be interested in working on 3 & 4? Jeff, are you
>> interested
>> as well? If so Craig, I, yourselves (and others that wish to join)
>> could
>> work in a branch of Jersey and when sufficiently progressed move to
>> the
>> trunk (i would be happy to do the integration).
>> Paul.
>>
>>
>> It seems to me there are five different functional aspects:
>> 1) multipart/* support
>> 2) multipart/form-data support
>> 3) Form beans from application/x-www-form-urlencoded
>> 4) Form beans from multipart/form-data
>> 5) General Java bean processing support.
>> 1) and 2) to be part of the same module, namely "jersey-multipart".
>> 3) an 4) could be part of a "jersey-form" module, which could
>> leverage one
>> or more external modules in 5), some suggestions of which you
>> present below.
>> Thoughts?
>> Paul.
>>
>> For actually doing the population, there's quite a lot of prior art
>> we could
>> look at as starting points, including things like Common BeanUtils
>> (which is
>> what Struts 1.x uses), the various JSF EL implementations (which
>> have to do
>> the same sort of thing), or even how Jersey itself performs
>> injections.
>>
>> Craig
>>
>> On Wed, Nov 5, 2008 at 6:50 PM, Kevin Duffey <andjarnic_at_yahoo.com>
>> wrote:
>>
>>
>> Kind of jumping in half way here.. but I actually recommended
>> someone to use
>> Jersey over other MVC frameworks to build both a MVC and REST
>> capable web
>> app. I like how it's possible to build MVC using Jersey and meanwhile
>> support REST too. Frankly, for my own stuff.. this is how I will
>> proceed
>> from now on.
>>
>> That said, I like the idea of allowing beans populated from form
>> data. I
>> take it Jersey will have to automatically determine that if
>> something like:
>>
>> public Response handleFormData(User user){
>> }
>>
>> where User is NOT a JAXB object..but instead an actual bean...
>> Jersey can
>> determine this correct? I didn't dig deep.. but I thought JAXB
>> objects have
>> various @XmlType annotations in it.. where as a regular bean would
>> have
>> nothing of the sort.. .maybe that would make it easy enough for
>> Jersey to
>> determine it's not a JAXB class. Just a thought... but I would see
>> this as a
>> great addition to allow for a bit more MVC like framework out of
>> Jersey.
>> However... is that starting to take Jersey into a direction of
>> being more
>> than a REST framework... even though it could be... is it trying to
>> be too
>> much? For me.. no.. but I could see how many may argue that Jersey is
>> becoming a bloated framework and not sticking to its core REST
>> capabilities.
>>
>>
>> ________________________________
>> From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
>> To: users_at_jersey.dev.java.net
>> Sent: Tuesday, November 4, 2008 2:16:20 AM
>> Subject: Re: [Jersey] Struts-like population of form beans
>>
>> Hi Jeff,
>> Apologies i forgot to reply on the wiki.
>> We don't support form beans yet, just @FormParam on the parameters
>> of a
>> resource method.
>> I think it is a good idea, for URL encoded or in general for
>> multipart
>> whether it be for form-data or other multi-parts, and it would be
>> good to be
>> part of Jersey. For multipart bean support we build upon Craig's
>> API. It
>> would be good to share bean processing functionality between URL-
>> based and
>> multi-part based beans.
>> Paul.
>> On Nov 4, 2008, at 1:22 AM, Robertson, Jeff wrote:
>>
>> Since we have Craig at our disposal here, I figure I'll bring this
>> up.
>>
>> Before I subscribed to the mailing list, I posted this on the wiki:
>>
>> http://wikis.sun.com/display/Jersey/getting+form+data+as+a+populated+javabean
>>
>> (Note: that code compiled against 0.9. Will not compile with 1.0)
>>
>> Does anyone thing this is something that should be in Jersey and/or
>> JAX-RS?
>> Not my implementation, which I worked on for less than an hour before
>> wikifying it, but the general idea?
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>