On Nov 7, 2008, at 2:52 PM, Robertson, Jeff wrote:
> Multiple values should populate arrays or collections. If the client
> sends multiple values for a property that is scalar, then use only the
> first or the last, not sure which.
>
For @*Param the first is picked.
> Default values and type conversions should follow rules defined
> elsewhere, as you suggest below.
>
Agreed.
> Validation as a feature should not be dependent on support for a
> particular representation like application/x-www-form-urlencoded.
> Jersey
> either needs validation across the board, or it doesn't.
>
I was thinking of validation of the form data w.r.t. application
semantics. The form bean may encapsulate that in some way.
Paul.
>
> -----Original Message-----
> From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> Sent: Friday, November 07, 2008 8:32 AM
> To: users_at_jersey.dev.java.net
> Subject: Re: [Jersey] Struts-like population of form beans
>
> 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+jav
> abean
>>>
>>> (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
>>
>
>
> ---------------------------------------------------------------------
> 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
>