camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] Assigned: (CAMEL-1117) improve Java DSL to reduce methods in ProcessorType
Date Wed, 17 Dec 2008 20:14:05 GMT


Claus Ibsen reassigned CAMEL-1117:

    Assignee: Willem Jiang

Willem do you mind take a look at this? You have done some of the work already today?

Basically reduce overloaded methods on ProcessorType and move options to the xxxType as fluent
builders. Keep on the most common methods in ProcessorType and leave the advanced options
as fluent builders on the xxxType.

We gotta get the 120-150 methods listed in the code completion list from the java editor when
end users use the Java DSL. It's to overwhelming with all these methods.

> improve Java DSL to reduce methods in ProcessorType
> ---------------------------------------------------
>                 Key: CAMEL-1117
>                 URL:
>             Project: Apache Camel
>          Issue Type: Improvement
>          Components: camel-core
>            Reporter: Claus Ibsen
>            Assignee: Willem Jiang
>             Fix For: 2.0.0
> 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:
> {code}
> from("xxx").splitter(body().tokenize(","), true, myPool).to("yyy");
> {code}
> After:
> {code}
> from("xxx").splitter(body().tokenize(",")).parrallel().threadPool(myPool).to("yyy");
> {code}
> See nabble:

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message