Marc Hadley wrote:
> On Feb 19, 2008, at 2:56 PM, Bill Burke wrote:
>>
>> Marc Hadley wrote:
>>> 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:
>>
>> Then why do we have @HeaderParam or @QueryParam? or even Providers?
>> They could be built easily using Httpheaders, UriInfo, and
>> InputStream respectively. i.e.
>>
> Taken to its logical conclusion why do we even bother with Java,
> everyone should just write bytecode directly ;-).
>
You're missing my point. @HeaderParam and @QueryParam only save one
line of Java code, so why have them? Cuz they are convenience functions
and make the code more readable. Same with the java bean mappings I'm
suggesting.
>> You're not saving a crazy alot of code here, but you are saving some,
>> and it looks more readable. These savings can be compounded if you
>> start reusing these mapped pojos in different methods and resources.
>>
> Thinking aloud, an alternative might be to allow an unannotated method
> parameter even for HTTP methods that don't have an entity body. Then you
> could have a custom message body reader conjur up the bean from whatever
> combination of request information is appropriate. That would let you
> write:
>
> @GET
> public String get(CustomerPK pk) {
> }
>
> public class CustomerPK {
> String first;
> String last;
> int ssn;
> }
>
> Not sure I like that, I think the current mapping from entity body to
> parameter is quite natural and this might confuse that.
>
I think that alternative should be allowed too. It really depends on
whether you want to decouple your mappings or not. Providers decouple,
annotations couple. Coupling isn't also a bad thing. You sould be
aware of the distributed protocol. You can always delegate to business
logic.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com