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
>>>
>>>
>>
>