[PROPOSAL] - Camel 2.0 - improve Java DSL to reduce methods in ProcessorType

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[PROPOSAL] - Camel 2.0 - improve Java DSL to reduce methods in ProcessorType

Claus Ibsen-2
Hi

Most of the Java DSL is defined in
org.apache.camel.model.ProcessorType so when you hit ctrl+space when
creating routes in Java DSL you get a list of 159 methods.

I have noticed during improving the javadoc that we overload the
methods to often, instead of having a few sensible defaults that
tailing 95% useage and then delegate the special customization to it's
own type where the fluent builder can offer the special methods.

For instance the splitter EIP has 12 methods to offer all kind of
combination of parameters. I think we should refactor this to allow
1-3 methods that should cater most usage and then add fluent builder
methods on the SplitterType so end user can do the special
customization there, where we can use good fluent builder methods
names (eg to enable something instead of true, it's parallel() then
it's much more readable

Before:
from("xxx").splitter(body().tokenize(","), true, myPool).to("yyy");

After:
from("xxx").splitter(body().tokenize(",")).parrallel().threadPool(myPool).to("yyy");



/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] - Camel 2.0 - improve Java DSL to reduce methods in ProcessorType

Willem.Jiang
Administrator
+1

It can be more readable, specially compares to the boolean argument of
the splitter construction ;)

Willem

Claus Ibsen wrote:

> Hi
>
> Most of the Java DSL is defined in
> org.apache.camel.model.ProcessorType so when you hit ctrl+space when
> creating routes in Java DSL you get a list of 159 methods.
>
> I have noticed during improving the javadoc that we overload the
> methods to often, instead of having a few sensible defaults that
> tailing 95% useage and then delegate the special customization to it's
> own type where the fluent builder can offer the special methods.
>
> For instance the splitter EIP has 12 methods to offer all kind of
> combination of parameters. I think we should refactor this to allow
> 1-3 methods that should cater most usage and then add fluent builder
> methods on the SplitterType so end user can do the special
> customization there, where we can use good fluent builder methods
> names (eg to enable something instead of true, it's parallel() then
> it's much more readable
>
> Before:
> from("xxx").splitter(body().tokenize(","), true, myPool).to("yyy");
>
> After:
> from("xxx").splitter(body().tokenize(",")).parrallel().threadPool(myPool).to("yyy");
>
>
>
> /Claus Ibsen
> Apache Camel Committer
> Blog: http://davsclaus.blogspot.com/
>

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] - Camel 2.0 - improve Java DSL to reduce methods in ProcessorType

Jon Anstey
Your suggestion looks nice to me. It is also more fluent. Also +1 for
shrinking the ProcessorType before it hits 2K lines :)

On Tue, Nov 25, 2008 at 5:02 AM, Willem Jiang <[hidden email]>wrote:

> +1
>
> It can be more readable, specially compares to the boolean argument of
> the splitter construction ;)
>
> Willem
>
> Claus Ibsen wrote:
> > Hi
> >
> > Most of the Java DSL is defined in
> > org.apache.camel.model.ProcessorType so when you hit ctrl+space when
> > creating routes in Java DSL you get a list of 159 methods.
> >
> > I have noticed during improving the javadoc that we overload the
> > methods to often, instead of having a few sensible defaults that
> > tailing 95% useage and then delegate the special customization to it's
> > own type where the fluent builder can offer the special methods.
> >
> > For instance the splitter EIP has 12 methods to offer all kind of
> > combination of parameters. I think we should refactor this to allow
> > 1-3 methods that should cater most usage and then add fluent builder
> > methods on the SplitterType so end user can do the special
> > customization there, where we can use good fluent builder methods
> > names (eg to enable something instead of true, it's parallel() then
> > it's much more readable
> >
> > Before:
> > from("xxx").splitter(body().tokenize(","), true, myPool).to("yyy");
> >
> > After:
> >
> from("xxx").splitter(body().tokenize(",")).parrallel().threadPool(myPool).to("yyy");
> >
> >
> >
> > /Claus Ibsen
> > Apache Camel Committer
> > Blog: http://davsclaus.blogspot.com/
> >
>
>


--
Cheers,
Jon

http://janstey.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] - Camel 2.0 - improve Java DSL to reduce methods in ProcessorType

Claus Ibsen-2
Created ticket for it

https://issues.apache.org/activemq/browse/CAMEL-1117

/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/



On Tue, Nov 25, 2008 at 1:26 PM, Jon Anstey <[hidden email]> wrote:

> Your suggestion looks nice to me. It is also more fluent. Also +1 for
> shrinking the ProcessorType before it hits 2K lines :)
>
> On Tue, Nov 25, 2008 at 5:02 AM, Willem Jiang <[hidden email]>wrote:
>
>> +1
>>
>> It can be more readable, specially compares to the boolean argument of
>> the splitter construction ;)
>>
>> Willem
>>
>> Claus Ibsen wrote:
>> > Hi
>> >
>> > Most of the Java DSL is defined in
>> > org.apache.camel.model.ProcessorType so when you hit ctrl+space when
>> > creating routes in Java DSL you get a list of 159 methods.
>> >
>> > I have noticed during improving the javadoc that we overload the
>> > methods to often, instead of having a few sensible defaults that
>> > tailing 95% useage and then delegate the special customization to it's
>> > own type where the fluent builder can offer the special methods.
>> >
>> > For instance the splitter EIP has 12 methods to offer all kind of
>> > combination of parameters. I think we should refactor this to allow
>> > 1-3 methods that should cater most usage and then add fluent builder
>> > methods on the SplitterType so end user can do the special
>> > customization there, where we can use good fluent builder methods
>> > names (eg to enable something instead of true, it's parallel() then
>> > it's much more readable
>> >
>> > Before:
>> > from("xxx").splitter(body().tokenize(","), true, myPool).to("yyy");
>> >
>> > After:
>> >
>> from("xxx").splitter(body().tokenize(",")).parrallel().threadPool(myPool).to("yyy");
>> >
>> >
>> >
>> > /Claus Ibsen
>> > Apache Camel Committer
>> > Blog: http://davsclaus.blogspot.com/
>> >
>>
>>
>
>
> --
> Cheers,
> Jon
>
> http://janstey.blogspot.com/
>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] - Camel 2.0 - improve Java DSL to reduce methods in ProcessorType

hadrian
+1. Awsome.

On Nov 25, 2008, at 7:51 AM, Claus Ibsen wrote:

> Created ticket for it
>
> https://issues.apache.org/activemq/browse/CAMEL-1117
>
> /Claus Ibsen
> Apache Camel Committer
> Blog: http://davsclaus.blogspot.com/
>
>
>
> On Tue, Nov 25, 2008 at 1:26 PM, Jon Anstey <[hidden email]> wrote:
>> Your suggestion looks nice to me. It is also more fluent. Also +1 for
>> shrinking the ProcessorType before it hits 2K lines :)
>>
>> On Tue, Nov 25, 2008 at 5:02 AM, Willem Jiang  
>> <[hidden email]>wrote:
>>
>>> +1
>>>
>>> It can be more readable, specially compares to the boolean  
>>> argument of
>>> the splitter construction ;)
>>>
>>> Willem
>>>
>>> Claus Ibsen wrote:
>>>> Hi
>>>>
>>>> Most of the Java DSL is defined in
>>>> org.apache.camel.model.ProcessorType so when you hit ctrl+space  
>>>> when
>>>> creating routes in Java DSL you get a list of 159 methods.
>>>>
>>>> I have noticed during improving the javadoc that we overload the
>>>> methods to often, instead of having a few sensible defaults that
>>>> tailing 95% useage and then delegate the special customization to  
>>>> it's
>>>> own type where the fluent builder can offer the special methods.
>>>>
>>>> For instance the splitter EIP has 12 methods to offer all kind of
>>>> combination of parameters. I think we should refactor this to allow
>>>> 1-3 methods that should cater most usage and then add fluent  
>>>> builder
>>>> methods on the SplitterType so end user can do the special
>>>> customization there, where we can use good fluent builder methods
>>>> names (eg to enable something instead of true, it's parallel() then
>>>> it's much more readable
>>>>
>>>> Before:
>>>> from("xxx").splitter(body().tokenize(","), true, myPool).to("yyy");
>>>>
>>>> After:
>>>>
>>> from
>>> ("xxx
>>> ").splitter
>>> (body().tokenize(",")).parrallel().threadPool(myPool).to("yyy");
>>>>
>>>>
>>>>
>>>> /Claus Ibsen
>>>> Apache Camel Committer
>>>> Blog: http://davsclaus.blogspot.com/
>>>>
>>>
>>>
>>
>>
>> --
>> Cheers,
>> Jon
>>
>> http://janstey.blogspot.com/
>>