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