For #1, totally agree that if a processor doesn't support dynamic properties then the UI element could be hidden or disabled.
For #2, I like the additional tab idea, it basically enables a decorator pattern on the processor to add attributes without any onus on any part of the flow to use them. Regards, Matt > On Aug 19, 2016, at 8:38 PM, Joe Witt <joe.w...@gmail.com> wrote: > > Kirk, > > As Matt points out dynamic properties of processors have meaning > specific to those processors. So, we need to be careful to avoid > complicating that. > > You raise two other points there though that I'd like to further discuss: > 1) Processors that don't really support dynamic properties should not > have the + icon present (or it should be disabled) > - I agree. Can you please raise a JIRA. > > 2) You'd like to be able to add a set of attributes to flow files that > exit a given processor and would like to be able to do this without > adding extra processors. > - I can see how this would be helpful and cleaner in some cases. I > envision that not as processor properties but rather a tab on > processor configuration that lets you tag flow file attributes on flow > files and which supports expression language. We should be really > clear where in the flow file lifecycle that tagging occurs such as on > session commit for example (so you know all other things in that > processor are done). Please raise a JIRA if this is consistent with > your idea. > > Thanks > Joe > > On Fri, Aug 19, 2016 at 12:14 PM, Tarou, Kirk > <kirk.ta...@verizonwireless.com.invalid> wrote: >> I think it would be beneficial to add dynamic properties to any processor >> for use further down the flow, not in the processor where the properties >> are added. >> >> For example, I may have a lot of ŒListSFTP¹ processors that feed into a >> single FetchSFTP, then a single PutFile. It would be nice to be able to >> add one or more attributes in ListSFTP to tell PutFile where to write the >> file or use RouteOnAttribute to send the file to the appropriate processor. >> >> I realize that this can be accomplished by adding an UpdateAttribute >> processor, but that would greatly increase the number of processors in my >> flow file. >> >> From a cursory scan of the 0.7.0 processors, it looks like >> UpdateAttribute, RouteOnAttribute, RouteOnContent, RouteText, >> HashAttribute and RouteHL7 are the only processors that actually allow you >> to add a property, yet all processors have the "+ New Property² widget on >> the ³Properties² page. If arbitrary properties can¹t be added, the ³+ New >> Property² widget should be hidden. >> >> - Kirk Tarou >> >> >> >>> On 8/18/16, 5:11 PM, "Matt Burgess" <mattyb...@gmail.com> wrote: >>> >>> Kirk, >>> >>> The processors have to explicitly know about dynamic properties (and >>> their intent) in order to use them appropriately. For a processor like >>> ListSFTP, it could be beneficial to have custom attributes (as >>> parameters to the SFTP session perhaps?) but the domain knowledge on >>> how they'd be used would have to be coded into the processor itself. >>> If you have a use case in mind, please feel free to file an >>> improvement Jira for ListSFTP to use dynamic properties. >>> >>> Regards, >>> Matt >>> >>> On Mon, Aug 8, 2016 at 4:50 PM, Tarou, Kirk >>> <kirk.ta...@verizonwireless.com.invalid> wrote: >>>> Is there some reason why Processors, like ListSFTP, don¹t allow custom >>>> attributes to be added? Relatedly, why do these processors allow users >>>> to add custom attributes & values in the UI even though it always throws >>>> the error: >>>> Œ[attribute]¹ validated against Œ[value]¹ is invalid because >>>> Œ[attribute]¹ is not a supported property >>>> >>>> - Kirk Tarou >>
