Hi
Also another idea could be to add a bit of javadoc to the fromXXX and
toXXX methods as they are the starting point, where we can add the
description of the component, so users can better see what it does.
And in the future when we have a new website with a more stable url,
we can add hyperlink to the component doc page.
Also I would like to see if we can include the "group" for each of
these options in the javadoc as a way of categorising what the option
is used for, eg common, security, scheduler.
Also if not implemented yet, then we should mark the methods as
@Deprecated if they are listed so in the json schema metadata.
On Wed, Jun 12, 2019 at 7:27 AM Claus Ibsen <claus.ib...@gmail.com> wrote:
>
> Hi
>
> Great work so far - love it.
>
> One little thing is that all endpoints inherit some options from the
> default endpoint which are seldom used. Maybe we could move these into
> an abstract base class, so they are not on the same "level" as all the
> other options, eg
>
> basicPropertyBinding
> synchronous
> bridgeErrorHandler
> exceptionHandler
> exchangePattern
> lazyStartProducer
>
>
> For example IDEA code completion would should parent methods in its
> list with a different colour than regular methods (bold).
>
> On Tue, Jun 11, 2019 at 7:39 PM Guillaume Nodet <gno...@apache.org> wrote:
> >
> > I think I'm done with a first usable pass at the endpoint DSL.
> > I've removed the getters/setters, added 2 flavors of fluent methods (one
> > with the real java type, another one with a String to allow references and
> > property placeholder processing), renamed the generated classes to
> > XxxEndpointBuilder and cleaned things a bit.
> > In order to access this API, one would create an EndpointRouteBuilder
> > anonymous class instead of the usual RouteBuilder (see below). The only
> > difference is that it gives immediate access to the fromXxx() and toXxx()
> > methods that are generated as default methods on the interface, so there's
> > no need to import anything else.
> > Please have a look and let me know what you think or if we see anything to
> > improve.
> >
> > Cheers,
> > Guillaume
> >
> > protected RouteBuilder createRouteBuilder() throws Exception {
> > return new EndpointRouteBuilder() {
> > @Override
> > public void configure() throws Exception {
> > from(fromFile(start).initialDelay(0).delay(10).move(done +
> > "/${file:name}"))
> > .to(toMock("result"));
> > }
> > };
> > }
> >
> >
> > Le mer. 5 juin 2019 à 23:23, Guillaume Nodet <gno...@apache.org> a écrit :
> >
> > > I just pushed a branch called "endpoint-dsl".
> > >
> > > My goal is to experiment with an auto-generated DSL for endpoints, mainly
> > > to have a complete and type-safe java DSL for endpoints instead of using
> > > URI containing all the parameters. Right now, it compiles but isn't
> > > really
> > > usable at a DSL.
> > > I'll get back as soon as I have something which can actually be used so
> > > that we can discuss further various options.
> > > My rough goal is to be able to write something like:
> > >
> > > from(file("target/data/foo").delay(4000).backoffMultiplier(4
> > > ).backoffIdleThreshold(2).backoffErrorThreshold(3))
> > > .to(mock("result"))
> > >
> > > instead of
> > >
> > > from(
> > > "file://target/data/foo?delay=4000&backoffMultiplier=4&backoffIdleThreshold=2&backoffErrorThreshold=3"
> > > )
> > > .to("mock:result")
> > >
> > > Stay tuned !
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> > >
> >
> > --
> > ------------------------
> > Guillaume Nodet
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
