Curl is in fact *exactly* the use case that led me to think of this. If
a web service is easily-curlable it has benefits beyond testing. Think
batch files, etc.
________________________________
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Wednesday, November 05, 2008 4:30 PM
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] Struts-like population of form beans
On Nov 5, 2008, at 10:09 PM, Robertson, Jeff wrote:
I did not propose this with the idea of Jersey being used as a web MVC
framework, I proposed because for some web *service* clients sending
form encoding will be easier than xml or json.
Agreed, it is like a property bag, easy to use with curl as well :-)
Paul.
Although I'm not opposed to using my idea to implement MVC, its a fringe
benefit for me. .
--------------------------
Sent using BlackBerry
----- Original Message -----
From: Kevin Duffey <andjarnic_at_yahoo.com>
To: users_at_jersey.dev.java.net <users_at_jersey.dev.java.net>
Sent: Wed Nov 05 12:50:48 2008
Subject: Re: [Jersey] Struts-like population of form beans
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?