If you base it on mime types then I don't see where there is a need for
a special annotation, unless you want extra behavior beyond just calling
some getters and setters.
________________________________
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Wednesday, November 05, 2008 4:08 PM
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] Struts-like population of form beans
Hi Kevin,
I think the high-level ease of use handling of form data is important
when building HTTP-based applications, especially RESTful MVC :-) HTML
forms are an integral part of "hyper media is the engine of application
state" and a great example to explain the approach, the form description
in HTML provides just enough information to tell the client how to
proceed to another application state.
If we could annotate the User bean with say @FormBean:
@FormBean
public class User {
}
then a message body reader could be implemented that checks for such
types. Further more there could be a reader for
"application/x-www-form-urlencoded" and "multipart/form-data". What is
nice is the User bean could also use the bean validation framework and
400 errors could be returned if the form data is invalid.
If we can support this using the extension mechanisms (as we are doing
for multipart support in general) then i do not think it becomes
bloated, as such functionality is a set components separate from the
Jersey core.
I also think there is a lot of potential to improve the MVC approach but
i have not had time to put some more TLC towards it.
Paul.
On Nov 5, 2008, at 9:50 PM, Kevin Duffey 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?