I think Aldrin's points about being able to use properties for the UI are pretty cool, but I also think there's room for the inverse (which is what I think the OP meant). The name of the processor is tied to its instance (though not guaranteed unique between instances, and definitely not unique between tasks within an instance). I would think any property/attribute/value associated with an instance of a processor should be available to it (so if name has been a "UI field", it would be no longer). The tradeoff, then, is when you have to name your processor a certain way to get it function correctly. I think this should not be the normal NiFi way, but should be available with the caveat that the documentation should reflect such a dependency. Sometimes when you're given enough rope to hang yourself, you build a bridge with it. Other times you just get dead :-P
Regards, Matt On Sun, Feb 21, 2016 at 3:25 PM, Aldrin Piri <[email protected]> wrote: > 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 > > > > > > > > >
