+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.
Brandon [1] https://docs.oracle.com/javase/tutorial/i18n/intro/quick.html On Thu, May 5, 2016 at 11:46 PM Adam Lamar <adamond...@gmail.com> wrote: > On Tue, May 3, 2016 at 12:09 PM, Andy LoPresto <alopre...@apache.org> > 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 >
