nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brandon DeVries <>
Subject Re: [discuss] PropertyDescriptor name and displayName attributes
Date Fri, 06 May 2016 12:44:34 GMT
+1.  I think being able to move the displayName out of code an into config
/ ResourceBundle will make it much easier to support i18n[1].  If no config
is provided, the name is the default... otherwise, the name displayed is
determined by the locale.  Updating the mock framework to complain about
the absence of a ResourceBundle will encourage adoption, and we'll
gradually work our way to not being English only.



On Thu, May 5, 2016 at 11:46 PM Adam Lamar <> wrote:

> On Tue, May 3, 2016 at 12:09 PM, Andy LoPresto <>
> wrote:
> > As a result of some conversations and some varying feedback on PRs, I’d
> like
> > to discuss with the community an issue I see with PropertyDescriptor name
> > and displayName attributes. I’ll describe the scenarios that cause issues
> > and my proposed solution, and then solicit responses and other
> perspectives.
> Andy,
> I'd be +1 on this as well. I think the power of this approach will
> become more clear over time, and some of the automation will make it
> possible to more widely enforce.
> What do you think about a mixed mode where config reading code can
> fetch the property value with either the name or display name as the
> key, defaulting to the name if it is present? A sample read of
> flow.xml.gz might look like this:
> * Processor asks for value of MY_CONFIG_PROPERTY
> * Configuration code looks for key "my-config-property", returns if present
> * Configuration code looks for key "My Config Property", returns if present
> * On finding no valid key, configuration returns blank/default/null
> value (whatever is done today)
> On configuration write, the new attributes could be written as the
> normalized name (instead of display name), to allow processors that
> have made the switch to start using the normalized name field and
> start taking advantage of the new features around it (e.g.
> internationalization). Perhaps a disadvantage to this approach is that
> it auto-upgrades an existing flow.xml.gz, making it difficult to
> downgrade from (for example) 0.7 back to 0.6.
> A strategy like this (or something similar) might help speed adoption
> by making the process a bit smoother for existing flow.xml.gz files
> and easier to upgrade processors incrementally. At 1.0, display names
> as configuration keys could be dropped, and the upgrade path for users
> on old 0.x releases would be to upgrade to the latest 0.x before
> making the jump to 1.0.
> Cheers,
> Adam

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message