camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <ja...@fusesource.com>
Subject Re: [Discuss] How to make the java DSL cleaner and less complex
Date Fri, 22 Jul 2011 10:50:19 GMT
On 22 July 2011 11:32, Guillaume Nodet <gnodet@gmail.com> wrote:
> On Fri, Jul 22, 2011 at 10:55, Christian Schneider
> <chris@die-schneider.net> wrote:
>> Hi all,
>>
>> I have taken a look at the current Java DSL. There i especially one thing
>> that bugs me.
>>
>> When we configure defintion like threads we do not clearly state where it
>> ends. So for example:
>>
>> from("seda:start").threads().executorService(pool).callerRunsWhenRejected(false).delay(1000).to("mock:result");
>>
>> So after threads() we can either configure the threads definition or go on
>> with the next definition. While this is very short it is also quite unclear.
>> Additionally the code completion in java mixes the threads attributes with
>> the other dsl elements. So it is more difficult for the user to see how the
>> threads can be configured.
>>
>> I can think of two alternative syntaxes that would be cleaner an help the
>> user better:
>>
>> 1. Using an end marker
>> from("seda:start")
>>    .threads().executorService(pool).callerRunsWhenRejected(false).end()
>>    .delay(1000).to("mock:result");
>> So after threads() the code completion will only show the attributes of
>> threads and the end() marker.
>>
>> 2. Configuring the definition using a Builder as a parameter:
>> from("seda:start")
>>    .threads(new
>> ThreadPoolProfileBuilder().executorService(pool).callerRunsWhenRejected(false).build())
>>    .delay(1000).to("mock:result");
>> The .build could be optional as we could accept a ThreadPoolProfile as well
>> as ThreadPoolProfileBuilder as an argument.
>>
>> Any opinions about that?
>
> Yes, scala rocks !!!

Agreed :)

> More seriously, if anything need to change (for 3.0 for example), what
> about something like
>
> from("seda:start")
>     .threads(executorService(pool).callerRunsWhenRejected(false))
>     .delay(1000).to("mock:result");
> rather than adding a new ThreadPoolProfileBuilder and a call to build ?

Yeah; the only downside with the paren then nested builder method
(e.g. "(" followed by "excutorService(...)" is it tends to break the
dot completion in IDEs. On the plus side, you get nice simple closing
of the mini-DSL expression on a ")" - on the downside typing
".threads(" then smart complete in your IDE - it often won't easily
show the right answer.

But yeah, I think separate builders for separate object trees make
sense. i.e. dot completion should really be reserved for patterns,
expressions & most common endpoints & data formats. Configuring beans
and strategies and whatnot are better done in separate builder APIs
and passed in as arguments; or created separately in a
guice/javaconfig/CDI kinda way.

-- 
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration and Messaging

Mime
View raw message