nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Witt <joe.w...@gmail.com>
Subject Re: [discuss] PropertyDescriptor name and displayName attributes
Date Fri, 06 May 2016 13:11:21 GMT
I share Bryan's perspective.

On Fri, May 6, 2016 at 9:05 AM, Bryan Bende <bbende@gmail.com> wrote:
> I might just be resistant to change, but I am still on the fence a little
> bit...
>
> In the past the idea has always been you start out with name, and if you
> later need to change what is displayed in the UI, then you add displayName
> after the fact.
>
> It sounds like the issue is that a lot of people don't know about
> displayName, so I am totally in favor of increasing awareness through
> documentation,
> but I'm struggling with telling people that they should set displayName as
> the default behavior.
>
> For code that is contributed to NiFi, I would expect the PMC/committer
> doing the review/merging to notice if an existing property name was being
> changed and point that out in the review.
> If it was someone else's custom NAR, or even made it through the review, I
> think what happens is that the flow starts up and the processor/component
> becomes invalid because it now has an unknown property.
> This is the same behavior when we remove a property from an existing
> processor and someone upgrades, and we deemed this acceptable behavior for
> that scenario.
>
> The internationalization aspect could possibly sell me more, but I think I
> would need someone to explain how internationalization would be
> implemented, and how setting the displayName helps.
> What Brandon described makes sense to me because it is something outside
> the Java code, which is different then saying all PropertyDescriptor
> instances need name and displayName.
>
> -Bryan
>
>
> On Fri, May 6, 2016 at 8:44 AM, Brandon DeVries <brd@jhu.edu> wrote:
>
>> +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 <adamonduty@gmail.com> wrote:
>>
>> > On Tue, May 3, 2016 at 12:09 PM, Andy LoPresto <alopresto@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
>> >
>>

Mime
View raw message