On Thu, Feb 21, 2013 at 11:25 AM, Łukasz Dywicki <l...@code-house.org>wrote:
> Keeping DSL syntax in core is caused by current design. Most popular camel > syntaxes do not support extensions by 3rd party elements (I mean Java and > XML). Everything then goes directly to core. That's wrong, that's really > bad. DSL should allow pluging new functors without problems. I mentioned > substitution group as desired design in XML Schema which will let us use > extensions. > Do you have any example of extensions working for spring or blueprint ? I can't find any good example from the top of my head, so I'm not even sure that it can actually be implemented (not from an xml perspective, but from a spring or blueprint one). > > To be honest, does camel-core care which dataformat is configured how? > Currently yes, however some of us already know it's not necessary. Camel > core should be separated from DSL. DSL should be built on top of core, not > otherwise. > > Cheers, > Lukasz > > Wiadomość napisana przez Willem jiang <willem.ji...@gmail.com> w dniu 21 > lut 2013, o godz. 04:06: > > > I think multiple DSL suppport is most important feature for Camel, as > our competitor just only support one or none of them. > > > > We got the some complains from the user that why does the Java DSL work, > but the Spring DSL doesn't work. They treat it a bug not a small syntactic > failure. > > > > It could be more easy if we can maintain the core module code in one > place. When you add no data format, you need to remember to update the > module class. > > > > BTW, We have lots of tests in Camel to make sure the Java DSL, Spring > DSL and other DSL do they job righty. > > > > -- > > Willem Jiang > > > > Red Hat, Inc. > > FuseSource is now part of Red Hat > > Web: http://www.fusesource.com | http://www.redhat.com > > Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) > (English) > > http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) > > Twitter: willemjiang > > Weibo: 姜宁willem > > > > > > > > > > > > On Thursday, February 21, 2013 at 10:49 AM, Hadrian Zbarcea wrote: > > > >> I strongly disagree. On what are you basing your "MUST" statement? > >> > >> There are 2 areas in which camel excels: one is the middleware > >> abstraction, via the api. The second is the runtime mediation. The dsl > >> has nothing to do with either, it's just syntactic sugar, eye candy. I > >> don't deny that it's helpful especially if well thought out. But I > >> certainly wouldn't go that far to state that there must be one > >> authoritative source. > >> > >> Cheers > >> Hadrian > >> > >> > >> On 02/16/2013 03:48 AM, Claus Ibsen wrote: > >>> On Sat, Feb 16, 2013 at 9:43 AM, Willem jiang > >>> <willem.ji...@gmail.com(mailto: > willem.ji...@gmail.com)> wrote: > >>>> Hi Henryk， > >>>> > >>>> The static import of Builder method could resolve the dependency > problem of Java DSL. > >>>> But when we move to the Spring XML or Blueprint, we still need a > DataFormat model to hold the reference in the camel-core. > >>> > >>> > >>> > >>> Yes there MUST be one authoritative source of the DSL which is the > >>> classes in the model package of camel-core. > >>> This model is then used to fully automatic generate the XML DSLs for > >>> spring and blueprint. This ensures we have a DSL that is in sync. > >>> > >>> > >>>> -- > >>>> Willem Jiang > >>>> > >>>> Red Hat, Inc. > >>>> FuseSource is now part of Red Hat > >>>> Web: http://www.fusesource.com | http://www.redhat.com > >>>> Blog: http://willemjiang.blogspot.com ( > http://willemjiang.blogspot.com/) (English) > >>>> http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) > >>>> Twitter: willemjiang > >>>> Weibo: 姜宁willem > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On Thursday, February 14, 2013 at 4:02 AM, Henryk Konsek wrote: > >>>> > >>>>>> This was the today's discussion on IRC (irc:// > irc.codehaus.org/camel (http://irc.codehaus.org/camel)). > >>>>> > >>>>> > >>>>> > >>>>> You seem to have a nice party here :) . I must join the next week. > >>>>> > >>>>> @Hadrian: > >>>>> SCXML component is something I wanted for Camel for a really long > >>>>> time. I like the library very much and it would be great to have it > in > >>>>> Camel. I'm glad you want to give it a chance. > >>>>> > >>>>> Regarding the Camel Core and DSLs - it would be great to move > >>>>> component-related DSL definitions from the core. For example XStream > >>>>> data format definition > >>>>> (org.apache.camel.model.dataformat.XStreamDataFormat) should be kept > >>>>> in the camel-xstream jar and somehow dynamically included in the DSL. > >>>>> I'm considering something similar to the the following snippet: > >>>>> > >>>>> import static org.apache.camel.dataformat.XStreamDslBuilder.*; > >>>>> ... > >>>>> from(...).marshal(xstream()).to(...); > >>>>> > >>>>> or even > >>>>> > >>>>> import static org.apache.camel.dataformat.XStreamDslBuilder.*; > >>>>> ... > >>>>> from(...).marshal(xstream).setXStream(...).to(...); > >>>>> > >>>>> > >>>>> In general static imports would be our friends here :) .I need to > >>>>> think about it and then I'll come with a concrete proposal. > >>>>> > >>>>> See you on the next IRC session (hopefully). > >>>>> > >>>>> -- > >>>>> Henryk Konsek > >>>>> http://henryk-konsek.blogspot.com > >>>> > >>> > >> > > > > > > > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
