I did most of it, time to get my hands dirty :)
To implement the form bean population, i would require a
"intercepting" component that could actualy do the trick. What
component is that that i am looking for? Is there a similar thing
implemented?
On Fri, Nov 7, 2008 at 4:41 PM, Craig McClanahan
<Craig.McClanahan_at_sun.com> wrote:
> 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.
>
>
>
> Here's what I did to get started:
>
> * Grabbed the JAX-RS specification document (pointer at
> https://jsr311.dev.java.net) and read it. It's not that long,
> but it's important to understand the portable part of the API
> that Jersey implements -- and so it's also clear when we
> are *using* the features of the spec (for example, by supplying
> extra providers and such) versus implementing them.
>
> * I always have the JSR-311 Javadocs open in a browser tab
> for easy reference.
>
> * Check out the source code of Jersey from java.net
> (instructions are on the website).
>
> * Build it locally (you'll need Maven for that).
> cd jersey
> mvn clean install
>
> * Start browsing the javadocs of the parts I was interested in (mostly
> jersey-core, jersey-server, and jersey-client).
>
> * When I wanted to explore an area in more detail, open up the sources
> for the unit tests and examine how they use the apis (NetBeans has a
> nice Maven plugin that lets you open each module as a project).
>
> * There are also sample apps that cover some of the interesting
> portions.
>
> * Ask questions on this list, often finding out that Paul and Jakub and
> others
> had already implemented pieces of what I needed ... I just didn't
> know where it was :-).
>
> Craig
>
>
> 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
>
>
>