On Nov 6, 2008, at 12:21 AM, Craig McClanahan wrote:
> Julio Faerman wrote:
>>
>> Speaking for my project, i would be a great thing. I would be able to
>> use only jersey for integration, AJAX and forms, reducing a lot of
>> clutter. But it is also a lot of work, specially when involving
>> master-detail beans, indexed properties, etc.
>>
>> Where to start? is it possible to do this in a contrib lib, like
>> jersey-multipart?
>>
> Serendipity is our friend, and least for part of this :-).
>
> It turns out that "multipart/form-data" is already correctly
> supported by jersey-multipart, and I just added a test case to
> verify it. The primary usability issue is that the current code
> leaves it up to the user to parse the parameter values from the
> Content-Disposition header.
And perhaps look up a body part given a name value equal to a name
value in the Content-Disposition header.
It is useful to look at the examples here:
http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2
Notice the two layers of embedding using multipart/mixed to upload a
collection of files. Also notice the filename property. When i
implemented form-data support for @FormParam a developer requested
access to the filename parameter, but i did not get around to
supporting this.
Does it make sense to have a FormDataMultiPart class, extend
MultiPart, which validates and encapsulates the form-data specific
functionality?
> That could get addressed by having jersey-multipart do a little
> more parsing (see previous discussion about something like a
> HeaderValue class that gives you the string value plus a map of
> parameter names/values for each header on the "Hello World! and
> Welcome to jersey-multipart" thread).
>
> This doesn't directly populate properties of a form bean ... but
> maybe the best organizational approach for that would be to build a
> jersey-htmlforms (or something) module that was focused on
> supporting "application/x-www-form-urlencoded" (including whatever
> bean population we like). Then, in one of the two modules, add some
> helper classes that take a bean and a MultiPart, and does the bean
> population stuff using a MultiPart as a source. It would be nice
> (from a jars-in-your-app perspective) to keep the two modules
> independent of each other, unless there was a significant amount of
> code needed by both.
>
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
>>
>>
>