I'll experiment a bit, but your suggestion looks promising.

Le mer. 12 juin 2019 à 15:24, Jan Bednář <pub...@janbednar.eu> a écrit :

> Hi all, one idea, how to keep clean file() instead fromFile() and
> toFile(). I have not checked full code of source branch, so apologize,
> if this is not possible to integrate for some reason.
>
> I think it is not needed to know if you are consumer or producer when
> creating builder. It can be switched to consumer/producer builder
> afterwards, when consumer/producer specific builder method is used.
>
> There could be two interfaces FileEndpointConsumerBuilder and
> FileEndpointProducerBuilder. Consumer builder interface holds common and
> consumer-only options. Producer builder interface holds common and
> producer-only options. Builder class implements
> FileEndpointConsumerBuilder and FileEndpointProducerBuilder. Common
> methods returns builder self. Producer-only methods returns builder
> casted to FileEndpointProducerBuilder. Consumer-only methods returns
> builder casted to FileEndpointConsumerBuilder;
>
> With this, first call to builder method, which is consumer-only returns
> FileEndpointConsumerBuilder and user is forced to use only common and
> consumer-only options for the subsequent calls.
>
> This is a bit strange, to have two different contracts for the same
> method in interfaces, but compiller does not complain about it.
>
> Small silly draft:
>
> public interface FileEndpointProducerBuilder extends EndpointBuilder {
>          FileEndpointProducerBuilder fileExist(GenericFileExist
> fileExist); // producer only
>          FileEndpointProducerBuilder autoCreate(boolean autoCreate); //
> common
>          FileEndpointProducerBuilder flatten(boolean flatten); //common
> }
>
> public interface FileEndpointConsumerBuilder extends EndpointBuilder {
>          FileEndpointConsumerBuilder recursive(boolean recursive); //
> consumer only
>          FileEndpointConsumerBuilder autoCreate(boolean autoCreate);
> //common
>          FileEndpointConsumerBuilder flatten(boolean flatten); //common
> }
>
> public class FileEndpointBuilderImpl implements
> FileEndpointProducerBuilder, FileEndpointConsumerBuilder {
>          private FileEndpoint endpoint;
>
>          public FileEndpointBuilderImpl(String path) {
>                  this.endpoint = new FileEndpoint();
>                  this.endpoint.setFile(new File(path)); // required
>          }
>
>          public FileEndpointConsumerBuilder recursive(boolean recursive)
> { // consumer only, return FileEndpointConsumerBuilder
>                  this.endpoint.setRecursive(recursive);
>                  return this;
>          }
>
>          public FileEndpointProducerBuilder fileExist(GenericFileExist
> fileExist) { // producer only, return FileEndpointProducerBuilder
>                  this.endpoint.setFileExist(fileExist);
>                  return this;
>          }
>
>          public FileEndpointBuilderImpl autoCreate(boolean autoCreate) {
> // common, return FileEndpointBuilderImpl which allows user to use all
> options
>                  this.endpoint.setAutoCreate(autoCreate);
>                  return this;
>          }
>
>          public FileEndpointBuilderImpl flatten(boolean autoCreate) { //
> common, return FileEndpointBuilderImpl which allows user to use all options
>                  this.endpoint.setFlatten(autoCreate);
>                  return this;
>          }
>
>          @Override
>          public Endpoint build() {
>                  return endpoint;
>          }
> }
>
>
> Dne 11.6.2019 v 23:36 Guillaume Nodet napsal(a):
> > Le mar. 11 juin 2019 à 20:45, Alex Dettinger <aldettin...@gmail.com> a
> > écrit :
> >
> >> Hey Guillaume, nice feature indeed.
> >> Just a detail when reading the example, I think one could be surprised
> to
> >> have x2 from/to at first glance, I mean:
> >> from(fromFile(... and to(toFile(...
> >>
> >>
> > I do agree.  My original idea was to only use file(xxx), but one
> constraint
> > is to have a different type for consumers and producers because they have
> > different options, so we can't use the same method name.  So the current
> > design is a fallback because I haven't found anything better, but I'm
> open
> > to suggestions ...
> >
> >
> >
> >> My 2 cents,
> >> Alex
> >>
> >>
> >>
> >> 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
> >>>
> >
>
>

-- 
------------------------
Guillaume Nodet

Reply via email to