nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre <andre-li...@fucs.org>
Subject Re: [DISCUSS] Component deprecation annotation
Date Mon, 01 May 2017 02:05:36 GMT
All,

Thank you for the feedback.

I will extend the PR so that the required endpoints are in place but will
leave the effective UI design to our UX experts.

Hopefully I should be able to use the @Restricted as a basis for this work.
Otherwise I will shout for some guidance.

Cheers


On Mon, May 1, 2017 at 11:23 AM, Joe Witt <joe.witt@gmail.com> wrote:

> Agreed on both the icon being preferable as the vehicle to show this
> for processors on the graph instead of color and also in emphasizing
> this during processor selection.
>
> Thanks
>
> On Sun, Apr 30, 2017 at 7:21 PM, Matt Burgess <mattyb149@gmail.com> wrote:
> > Visual indication on existing processors is a good thing, but IMO we'll
> definitely need indication on the processor selection dialog, so the user
> will know that we suggest they choose an alternative.
> >
> > Regards,
> > Matt
> >
> >> On Apr 30, 2017, at 7:12 PM, Jeff <jtswork@gmail.com> wrote:
> >>
> >> I think an icon on the processor would be best to denote an upcoming
> >> deprecation.  That leaves all colors available to the flow design, since
> >> any color may have specific meaning to any current flow out there.
> >>
> >>> On Sat, Apr 29, 2017 at 3:58 PM Juan Sequeiros <hellojuan@gmail.com>
> wrote:
> >>>
> >>> In same train of though maybe make it default to some color other than
> >>> white, instinct says red but that might be used to represent an
> important
> >>> processor. So suggest maybe default beige?
> >>>
> >>>
> >>> On Sat, Apr 29, 2017 at 8:20 AM Andy LoPresto <
> alopresto.apache@gmail.com>
> >>> wrote:
> >>>
> >>>> I'd leave the graphics work/decisions to someone like Rob Moran, but
I
> >>> see
> >>>> it as similar to the restricted components -- an icon on the
> processors
> >>> on
> >>>> the canvas and the dialog to add components, with additional
> explanation
> >>>> (and maybe a target release for full deprecation) in the help notes.
> >>>>
> >>>> Andy LoPresto
> >>>> alopresto@apache.org
> >>>> alopresto.apache@gmail.com
> >>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >>>>
> >>>>> On Apr 29, 2017, at 05:16, Andre <andre-lists@fucs.org> wrote:
> >>>>>
> >>>>> dev,
> >>>>>
> >>>>> In light of the some recent deprecations (ListenLumberjack) and
some
> >>>>> potential deprecation (PutJMS/GetJMS) I started some progress on
how
> to
> >>>>> document the depreciation of NiFi components using annotations.
> >>>>>
> >>>>> In the absence of any better name I called the annotation
> >>>>> @DeprecationWarning (so not overlap with Java's @Deprecated)
> >>>>>
> >>>>> The suggested modifications are part of PR#1718 and I am keen to
hear
> >>>> your
> >>>>> thoughts.
> >>>>>
> >>>>> While the documentation can be displayed as part of the usage,
> however
> >>> I
> >>>>> would imagine the frequency a user browses to the usage pages will
> >>> reduce
> >>>>> as her/him becomes familiar with the components.
> >>>>>
> >>>>> In light of this it may be a good idea to use  the web UI to
> highlight
> >>> a
> >>>>> processor has been deprecated.
> >>>>>
> >>>>> Would anyone suggest a way of doing so without disrupting the user
> >>>>> experience?
> >>>>>
> >>>>> Cheers
> >>>>
> >>>
>

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