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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > >> 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 <[email protected]> > 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 <[email protected] > > > >> > > 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 > >> > > > >> > > >> > > > > >
