Within the NiFi codebase we only have a single example of a content viewer that is loaded at runtime using the extension point I described here. That is the Standard Content Viewer. It can be found here [1]. At startup, NiFi will discover files that meet the following criteria [2] similar to how other extensions are discovered using Java SPI. In my last response, I mentioned that the contract is largely unchanged when compared to the 1.x baseline. This is one of those differences and will be discussed in the migration guide for 2.0.0-M5 when that release happens. The nifi-content-viewer file now contains a listing of content types categorized by a display name that the user will see in the base Content Viewer.
Regarding the slide panel, that doesn't sound like an "extension point" but rather a new capability that could be contributed. For a UI "extension" it would be something to allow a developer to provide a UI that we load into the NiFi UI. Typically these would also include APIs or Controllers that integrate with a contract that the NiFi Framework supports for that "extension point". For instance, in this content viewer example NiFi offers the ContentAccess API for accessing content which is then used in an endpoint supporting Standard Content Viewer UI. Let me know if you have further questions. Matt [1] https://github.com/apache/nifi/tree/main/nifi-extension-bundles/nifi-standard-bundle/nifi-standard-content-viewer [2] https://github.com/apache/nifi/blob/main/nifi-extension-bundles/nifi-standard-bundle/nifi-standard-content-viewer/src/main/webapp/META-INF/nifi-content-viewer [3] https://github.com/apache/nifi/blob/main/nifi-extension-bundles/nifi-standard-bundle/nifi-standard-content-viewer/src/main/java/org/apache/nifi/web/controller/StandardContentViewerController.java#L67 On Sat, Sep 21, 2024 at 11:07 AM Mark Bean <mark.o.b...@gmail.com> wrote: > For clarification, previously we were unpacking the WAR - simply by > unzipping it using a plugin - and then adding and in some cases replacing > JSP files. Then, the WAR was recreated (again, just zipping into a .war > file). Admittedly, this is not a desirable approach which is why I was > asking about natural extension points. > > I will take another look based on your suggestions. It's not > immediately obvious to me how or where a custom WAR would be recognized by > the UI. Do you have an example to point to, or a class/interface that is > the hook for the extension? > > Regarding the content viewer, we have a customized viewer with a slide > panel that shows FF details/attributes alongside the content pane. I'm not > sure this type of extension is what you have in mind or is possible. > Rather, I think you are saying that a custom viewer would support the > content pane itself. Is that correct? If the slide panel isn't an > appropriate extension, at least this feature of all mentioned seems like an > appropriate contribution to the base content viewer. > > Thanks, > Mark > > > > On Sat, Sep 21, 2024 at 10:47 AM Matt Gilman <matt.c.gil...@gmail.com> > wrote: > > > Mark, > > > > There are "extension points" in the UI for Advanced UIs and Content > > Viewers. The capability is largely unchanged from the 1.x baseline in > that > > WARs are discovered at runtime and are associated with specific > components > > or content types. The UIs themselves do not need to be part of the > > nifi-frontend module. This project just allows all UIs provided by Apache > > NiFi itself to share a common set of dependencies, reuse components, > > styles, etc. But any WAR that meets the criteria (the same criteria as > the > > 1.x baseline) will be deployed and the extension UIs will be available in > > the UI. > > > > There are no further optimizations for the banner text. It is intended to > > allow a text string to be configured. There is also no ability to > provide a > > custom logo. > > > > The Content Viewer is designed to support viewing a single piece of > > content. This is any piece of content in a Queue or referenced as > > input/output of a Provenance Event. If in your scenario the text/metadata > > and image were within the same piece of content it would be doable > through > > this extension point. If not, a new extension concept may be needed if > the > > scenario could be generalized and would be helpful in other cases. If > not, > > you could fork the codebase and implement purpose built UIs for your > > specific use cases. > > > > It's not clear based on your last paragraph how the UIs were previously > > being modified with a custom build. If you mean that you were manually > > modifying the UI components and rebuilding, that is still possible in 2.x > > it's just the UIs were built differently. > > > > Matt > > > > On Sat, Sep 21, 2024 at 10:16 AM Mark Bean <mark.o.b...@gmail.com> > wrote: > > > > > I am investigating the options available (or not) for extending > elements > > of > > > the UI. I have three specific examples, but the question is also the > > > general case: can the UI be extended by custom visualization and/or > > > behavior. > > > > > > Three examples are header, footer and content viewer. It is desirable > to > > > have decoration added to the otherwise available property > > > "nifi.ui.banner.text" (nifi.properties.) For example, users may want to > > > change the text color, background color or display multi-line text. As > > for > > > the header, it would be interesting to be able to change the NiFi logo > > to a > > > company logo or instance/cluster-specific graphic. > > > > > > Lastly, the content viewer seems an ideal place for extension as some > > file > > > formats may have different display requirements; consider the case of a > > mix > > > of text (metadata) and image. Moreover, the format itself may be > > > proprietary so the details of a viewer cannot be contributed back to > > Apache > > > NiFi. > > > > > > For NiFi 1.x, it was possible to inject JSP for options such as these - > > not > > > trivial, but possible with a custom build. For NiFI 2.x, the nifi-ui > WAR > > > packaging does not appear to be as easily modified even in a custom > > build. > > > > > > Thanks in advance for guidance or suggestions. > > > > > > -Mark > > > > > >
