I think the functionality is certainly useful and like the deduplication,
certainly a great idea to be a bit more efficient. However, I find myself
a bit hesitant to drive processor configuration via the processor UI
fields. At first thought, I think something along the lines of EL that
could make use of processor properties for UI components like name and
potentially notes could be helpful. In this case, the processor UI could
have its name be defined as something akin to "Retrieve data from ${url}
every ${run.time}"
Obviously some caveats would be needed such as handling the case of a
property that is also using EL likely wouldn't work, but personally find
driving presentation from processor logic to be more intuitive than the
inverse.
On Sun, Feb 21, 2016 at 7:45 AM, Joe Witt <[email protected]> wrote:
> Richard,
>
> I don't believe the processor name (as you see in the UI or through
> the REST API) is made available to the processor instance itself at
> this time. There is no strong/obvious case I can think of quickly to
> restrict access to the logical name of a ConfigurableComponent like
> this.
>
> Other opinions?
>
> Thanks
> Joe
>
> On Sun, Feb 21, 2016 at 8:32 AM, Richard Miskin <[email protected]>
> wrote:
> > Hi,
> >
> > I’ve a use case where each instance of a custom Processor on my flow
> represents a different instance of a remote system. The message produced by
> my Processor needs to include the remote system name, and currently I’m
> using a PropertyDescriptor to allow this to be configured. This means that
> the name is effectively set twice, once to be shown in the UI and once to
> be used by my Processor internally. This leads to the possibility of the
> two values being inconsistent which is likely to confuse people in future.
> >
> > Is there any way I can access the name of a Processor from within an
> AbstractProcessor?
> >
> > Cheers,
> > Richard
> >
> >
>
