On Sun, Apr 19, 2009 at 8:44 PM, Roman Kalukiewicz <[email protected]> wrote: > Hello Claus, > > You asked for thoughts, so here they are ;) Great the more the better. This is now you have the chance to influence the API before 2.0 is settled. So please reply with any thoughts you have. The producertemplate is very useful so we want to provide a API that intuitive and you can use without being in doubt.
> > What about totally different approach, that would be a pattern > parameter instead of a method name. Especially that those methods > differ only in pattern set on the exchange. > > In fact I believe the best approach would be to have sendMessage() > method that has pattern as a parameter and is overloaded with versions > for sending only body, only one header, and a map of headers. Why the > method name has to show what parameters already clarify? I see two/three issues with the combined method approach 1) The method must be delcared to return something. That is a drawback for InOnly methods where you can use void. This was confusing in 1.x as people would thing that are doing an InOut but the have selected a InOnly method but in the 1.x API it would still return something, and in some of the older 1.x releases it was the IN payload you sent. And with the void we get help from the compiler if the end users things he is doing and InOut and expects an output. 2) You have to specify the pattern using an enum and thus you need imports and the method parameters get long and/or you can use static imports to shorten it. But it all takes time to setup in the IDE and well ... it just feels like a drag in 95% if the uses cases where you either use InOnly or InOut. 3) We should also consider being similar to the other integration projects in this matter. Spring Integration uses 2 different method signatures. Mule as well AFAIR And now we are talking about this API. What about: 4) The API in ProducerTemplate have grown to large IMHO. So I also suggest to reduce it and use specialized methods for the 95% use cases. And the provide a few fallback methods that you can use for the other 5%. And we should consider not having copies with both String endpointUri and Endpoint as the object. You can always go from Endpoint -> endpointUri so we should consider removing some of the Endpoint variations. > > Romek > > 2009/4/19 Claus Ibsen <[email protected]>: >> Hi >> >> Actually I think the naming convention should be: >> >> send = for in only >> sendWithHeader >> sendWithHeaders >> >> sendAndReceive = for in out >> sendAndReceiveWithHeader >> sendAndReceiveWithHeaders >> >> Its more intuitive than currently >> send = for in only >> request = for in out >> >> However what about the "body" method we can do it like >> >> sendAndReceiveBody >> sendAndReceiveBodyWithHeader >> sendAndReceiveBodyWithHeaders >> >> or >> >> sendBodyAndReceiveWihHeader >> sendBodyAndReceiveWithHeaders >> >> I prefer the former as its sending a body and receving a body. >> >> >> Any thoughts on this, as we still have time to for this API change >> before 2.0 is ready for release. >> However the clock is ticking!!! >> >> >> >> >> On Sat, Apr 4, 2009 at 9:20 AM, Claus Ibsen <[email protected]> wrote: >>> On Sat, Apr 4, 2009 at 8:38 AM, Ryan Gardner <[email protected]> wrote: >>>> The requestBody method makes sense (it requests a body) - but >>>> "requestBodyAndHeader" and "requestBodyAndHeaders" etc methods make less >>>> sense - because I'm only requesting one thing (the body). >>>> >>>> maybe "requestBodyWithHeader" makes more sense? for the "sendBodyAndHeader" >>>> methods, it makes sense because you are sending two things (the body and >>>> the >>>> header) >>>> >>>> although, perhaps I'm just going crazy? >>> No it makes sense. You only get the body as reply. >>> >>> But to make it consistent the sendBodyAndHeader could also be named as >>> sendBodyWithHeader. >>> >>>> >>>> Ryan >>>> >>> >>> >>> >>> -- >>> Claus Ibsen >>> Apache Camel Committer >>> >>> Open Source Integration: http://fusesource.com >>> Blog: http://davsclaus.blogspot.com/ >>> Twitter: http://twitter.com/davsclaus >>> Apache Camel Reference Card: >>> http://refcardz.dzone.com/refcardz/enterprise-integration >>> >> >> >> >> -- >> Claus Ibsen >> Apache Camel Committer >> >> Open Source Integration: http://fusesource.com >> Blog: http://davsclaus.blogspot.com/ >> Twitter: http://twitter.com/davsclaus >> Apache Camel Reference Card: >> http://refcardz.dzone.com/refcardz/enterprise-integration >> > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus Apache Camel Reference Card: http://refcardz.dzone.com/refcardz/enterprise-integration
