Scott,

Where does the UI/documentation stand on adding custom controls to
processors? That's a feature that I could see being really useful. An
example is a processor I've thought about writing called
RouteOnFlowfileSize that would let users define relationships based on
flowfile size ranges. Having sliders would be critical to making that
user-friendly.

On Fri, Feb 23, 2018 at 8:28 AM, Scott Aslan <scottyas...@gmail.com> wrote:

> Mike Thomsen,
>
> The Ui is being standardized on Angular. NiFi is currently running
> AngularJS v1.5.11 while NiFi Registry is running Angular v4.4.6.
>
> On Fri, Feb 23, 2018 at 8:23 AM, Scott Aslan <scottyas...@gmail.com>
> wrote:
>
> > Micheal M.,
> >
> > A *Design System* is a collection of utilities, components, and
> > guidelines which define the overall structure and experience of an
> > application(s). Fluid is the name of this design system.
> >
> >
> >
> > On Thu, Feb 22, 2018 at 1:44 PM, Michael Moser <moser...@gmail.com>
> wrote:
> >
> >>  There are compelling pros and easily identifiable cons to placing UI
> >> components into their own project.  I don't have anything to add there.
> >>
> >> Please, however, consider a different name.  "Fluid Design System" is
> >> generic to the point of giving no cognitive clue about what it actually
> >> is.  And without that clue, it's no different than a shorter made-up
> word.
> >> Also, a quick Google search doesn't indicate that it's an industry
> >> accepted
> >> phrase that conveys meaning.
> >>
> >> Consider:
> >>
> >> Fluidifi
> >> NiFi Fluid UI
> >> NiFi UI Components
> >> NiFi FDS
> >>
> >> Thanks,
> >> -- Mike
> >>
> >>
> >> On Thu, Feb 22, 2018 at 1:43 PM, Scott Aslan <scottyas...@gmail.com>
> >> wrote:
> >>
> >> > Joe,
> >> >
> >> > Yes, extract out the FDS.
> >> >
> >> > As for a release schedule, I don't think there would need to be one.
> We
> >> > would put out new releases as needed for new features or components.
> >> These
> >> > releases would be totally independent of NiFi or NiFi Registry. The
> >> > intention with this project is to follow semantic versioning and avoid
> >> > making breaking changes so using this library in NiFi or the NiFi
> >> Registry
> >> > would be as simple as updating the version number in the package.json
> >> and
> >> > rebuilding the application.
> >> >
> >> > As for validation of releases I have a couple of ideas. I envisioned
> >> this
> >> > code base would follow a RTC paradigm and the initial release of this
> >> FDS
> >> > NgModule would include unit test coverage of all the existing
> >> > features/components/utils. Any new features/components/utils would
> >> require
> >> > adequate test coverage before being merged to NiFi FDS master. We
> could
> >> > also provide a demo application that users can build and deploy
> locally
> >> to
> >> > allow for human verification or even e2e testing...
> >> >
> >> > I took the liberty of standing up a repo to give everyone a better
> idea
> >> of
> >> > what we are all talking about.
> >> > https://github.com/scottyaslan/fluid-design-system
> >> >
> >> > Since no server or backend is required to run these UI/UX components I
> >> also
> >> > stood a demo of this as a github.io page here:
> >> > https://scottyaslan.github.io/fluid-design-system/
> >> > <https://scottyaslan.github.io/fluid-design-system/>
> >> >
> >> > -Scotty
> >> >
> >> > On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt <joe.w...@gmail.com>
> wrote:
> >> >
> >> > > Scott
> >> > >
> >> > > Ok so extract out the fluid design work you started with NiFi
> Registry
> >> > > to its own codebase which can be rev'd and published to NPM making
> it
> >> > > easier to consume/reuse across NiFi projects and offers better
> >> > > consistency.  This sounds interesting.
> >> > >
> >> > > In thinking through the additional community effort or the effort
> >> > > trade-off:
> >> > > How often do you anticipate we'd be doing releases (and thus
> >> > > validation/voting) for this?
> >> > > How often would those differ from when we'd want to do a NiFi or
> NiFi
> >> > > Registry release?
> >> > > How do you envision the community would be able to help vet/validate
> >> > > releases of these modules?
> >> > >
> >> > > Thanks
> >> > > Joe
> >> > >
> >> > > On Thu, Feb 22, 2018 at 8:18 AM, Scott Aslan <scottyas...@gmail.com
> >
> >> > > wrote:
> >> > > > NiFi Community,
> >> > > >
> >> > > > I'd like to initiate a discussion around creating a sub-project of
> >> NiFi
> >> > > to
> >> > > > encompass the Fluid Design System NgModule created during the
> >> > development
> >> > > > of the NiFi Registry. A possible name for this sub-project is
> simply
> >> > > > "NiFi Fluid
> >> > > > Design System". The idea would be to create a sub-project that
> >> > > distributes
> >> > > > an atomic set of high quality, reuse-able, theme-able, and
> testable
> >> > UI/UX
> >> > > > components, fonts, and other JS modules for use across the various
> >> web
> >> > > > applications throughout the NiFi universe (uNiFiverse???). Both
> NiFi
> >> > and
> >> > > > NiFi Registry web applications would eventually leverage this
> module
> >> > via
> >> > > > npm. This approach will enable us to provide our users with a
> >> > consistent
> >> > > > experience across web applications. Creating a sub-project would
> >> also
> >> > > allow
> >> > > > the FDS code to evolve independently of NiFi/NiFi registry and be
> >> > > released
> >> > > > on it's own timeline. In addition, it would make tracking
> >> issues/work
> >> > > much
> >> > > > clearer through a separate JIRA.
> >> > > >
> >> > > > Please discuss and provide and thoughts or feedback.
> >> > > >
> >> > > > Thanks,
> >> > > >
> >> > > > Scotty
> >> > >
> >> >
> >>
> >
> >
>

Reply via email to