On Feb 19, 2008, at 1:15 PM, Bill Burke wrote:
> I just showed you an example where IAGNI, so I fail to see your point.
Your example could easily be covered by the existing stuff we have:
GET
http://host.com/customerdb/;first=Bill;last=Burke;ssn=444-44-4444
@Path("/customerdb/{customerid}")
@GET
public String get(@MatrixParam("first") String firstName,
@MatrixParam("last") String lastName, ...) {...}
or
@Path("/customerdb/{customerid}")
@GET
public String get() {
CustomerPK c = new CustomerPK(uriInfo.getMatrixParameters());
...
}
> The below example could easily be passed to a JPA query. I am sure
> there are other use cases we haven't thought of for JavaBean
> mappings beyond forms. I could see a user combining information
> from PathParams,MatrixParams, and even QueryParam to make up an
> Identity POJO as I showed already. I could see HeadParams and
> CookieParams being combined to create a protocol or policy bean.
>
> This is a mapping specification, so let's provide some more complex
> mapping scenarios. As long as the simple cases are still simple, I
> don't see the harm.
The harm is complicating the API. Your example already overloads
@PathParam and introduces an entirely new API component.
> This whole specification is a convenience spec in which any of the
> services could be written as a Servlet. So, let's make it
> convenient and expressive for as many use cases as we can think of
> even if they are corner cases.
>
I disagree, I think we need to apply an 80/20 rule to anything we
include in the spec.
Marc.
>
> Marc Hadley wrote:
>> I agree that better support for forms is desirable and I quite like
>> the idea of mapping form-url-encoded and multipart form data to a
>> Java bean. Beyond that though I think we are entering YAGNI
>> territory and already offer enough through UriInfo and HttpHeaders.
>> Marc.
>> On Feb 18, 2008, at 11:26 AM, Bill Burke wrote:
>>> I wanted to take Pauls form idea even further and be able to
>>> combine it with a @PathParam. Consider this scenario
>>>
>>>
>>> GET http://host.com/
>>> customerdb/;first=Bill;last=Burke;ssn=444-44-4444
>>>
>>>
>>> @Path("/customerdb/{customerid}")
>>> @GET
>>> public String get(@PathParam("customerid") CustomerPK cust) {...}
>>>
>>>
>>> @Mapped
>>> public class CustomerPK {
>>>
>>> @MatrixParam("first") String firstName;
>>> @MatrixParam("last") String lastName;
>>> @MatrixParam("ssn") String socialSecurityNumber;
>>>
>>> ...
>>>
>>> }
>>>
>>> and support setter injection too.
>>>
>>>
>>>
>>> So in review, I'd like to support JavaBean creation/injection in
>>> these scenarios:
>>>
>>> * Form urlencoded (as Paul suggested) with no arguments as Paul
>>> suggested
>>> * As just an a arbitrary parameter so that you could map any piece
>>> of the HTTP request into the JavaBean
>>> * in conjunction with @PathParam so you could extract matrix
>>> params easily.
>>>
>>>
>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>>>
>> ---
>> Marc Hadley <marc.hadley at sun.com>
>> CTO Office, Sun Microsystems.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.