This guide presumes that you have a bit of experience using Workbench, the Property Sheet, and Px Graphics. It also presumes that you have some exposure to the Niagara Type system and Object Model, which is documented elsewhere in the Developer Guide.
Widget is the base class that encapsulates some defined bit of UI behavior. A Widget can be as simple or as complex as you like. In Niagara UI, basically everything is a Widget.
A label that does nothing but draw a string? That’s a Widget. A checkbox? Widget. A Property Sheet? Widget. The entire usable view space of Workbench itself? Yep, that’s a Widget.
A Field Editor is a Widget that displays a data value - a Field - and allows the user to make changes to it.
Most of the time, Field Editors are used for Simples (like strings and numbers), and sometimes, simple Structs. Field Editors on Components are much less common.
Edit a Component, such as a User, in the Property Sheet. You’ll get small, inline editors allowing you to edit each property - each “field” - of that User. Those small widgets are Field Editors.
In more recent HTML5-based UI code, we’ve been referring to these simply as Editors. This is because the value being edited doesn’t necessarily have to be a “field” of some parent component - it can be a standalone value.
We usually use “View” to refer to a piece of UI that is “fullscreen” - it takes up the entire content pane of Workbench while you’re looking at it. Some examples are Property Sheet and User Manager.
In practical terms, the only difference between a View and a Field Editor is the amount of space it takes up - Views are large, Field Editors are small. But because Views often take up the entire UI content pane, they may integrate more tightly with the profile itself. They may provide Commands to the toolbar or menu bar, or support transfer Commands like copy/pasting from the nav tree.
Px GraphicsPx allows you to develop your own UI with no programming necessary. It works by identifying the different Widgets you want on your page, drag-and-dropping them on, and binding them to real-time data from your station. It’s a bit similar to existing web page builders like Wix or Squarespace - but it’s Niagara-specific, the editor is Java-based, and works in Workbench. (You might see the terms “Px graphic” or “Px page” - these mean the same thing.)
Some common operations you might do in Px are:
You won’t have to write code to develop Px pages. But if you want to create a custom Widget to embed in Px pages, because the provided set of Widgets don’t cater to your particular use case, then you’ll need to code one up.
PxMediaEvery Px graphic has an associated Media Type. Here is an overview of what media are available and how they are used.
Niagara provides a rich set of frameworks and tools to assist you in developing your own custom UI. This section will describe what’s available, so you can decide on which tools will best serve your own use cases.
bajaui: from AX to N4bajaui is Niagara’s Java-based UI component framework that has been in use since the very first release of Niagara AX.
bajaui code is based entirely on the Niagara type system. Every bajaui widget extends bajaui:Widget, which itself extends baja:Component. Therefore, bajaui-based UI uses the Niagara component model to work. Because it is Java-based, bajaui code only works in Workbench or another Java-based application like Web Launcher.
The requirement that Workbench or Web Launcher be used may mean that new bajaui development may be unattractive; many applications require that the user be able to simply log in via the browser with no downloads or plugins required.
When starting up AX Workbench, every bit of UI you see is based upon bajaui. In Niagara 4, many views are implemented using our HTML5 framework, bajaux. But many views and field editors are still based upon bajaui. In the cases where a HTML5 version of a view is available, the legacy bajaui version may be prefixed with “AX”, as in “AX User Manager.”
Hx: bringing bajaui to the browserHx is Niagara’s first framework to target native HTML and JavaScript. It was introduced in Niagara AX 3.0, and heavily reworked in 3.5. Hx widgets work by essentially writing HTML5 and JavaScript, in Java: you’ll implement an Hx class that’s an analog of your original bajaui Widget, and that class will use Java to generate a series of HTML strings and JavaScript calls.
In other words, even though your Hx UI is used natively in the browser, the actual UI resides inside your Niagara station. Your browser serves almost as a “thin client,” simply displaying the HTML and JavaScript as dictated by the station itself.
There are a number of views implemented in Hx such as Property Sheet, User Manager and Scheduler, but most of those views have severely reduced functionality compared to the original bajaui views, and they are largely deprecated or removed.
However, Hx is still actively supported and in widespread use in the HxPx framework, which displays Px graphics in the browser using HTML5 and JavaScript.
bajaux: bringing N4 into the age of the Webbajaux is Niagara’s JavaScript-based UI component framework, natively targeting the browser. It has been in use since Niagara 4.0.
bajaux code itself does not directly use the Niagara type system. Every bajaux widget extends the base class Widget, which is not a Niagara type. However, in practice, bajaux works closely together with the Niagara type system to help draw relationships between Niagara types and the kind of widgets that should be used to work with those types.
Because bajaux is entirely HTML5- and JavaScript-based, it can be used directly in the browser with no plugins required. While Hx generates the UI on the station, bajaux generates it directly in the browser.
In addition, the open nature of bajaux means that it is one of the best options for making use of the many open-source JavaScript tools and frameworks available.
bajaux and Workbench work togetherEven though bajaux views are implemented purely in JavaScript, they will still work natively within Workbench! This is because Workbench contains a web browser embedded directly within it. When you load a bajaux-based view, an instance of this web browser is displayed - like opening a new browser tab. Workbench itself (using Java), and the bajaux view (using JavaScript), can then communicate with each other using a Java-JavaScript interop layer implemented custom for Workbench.
This interop allows for features like the following:
bajaux viewsCommands provided by the bajaux View will appear in Workbench’s toolbar and menu barbajaux view will handle a drag and drop from Workbench’s nav tree or palette sidebarsbajaui will continue to be supported for the foreseeable future. Hundreds of different bajaui views are still in widespread use around the globe, and they will not be abandoned. As long as Workbench is supported, so will bajaui be. It is well-established and stable, so major enhancements or API changes will be very infrequent.
However, the general trend is for users to access the UI directly through the browser, and so the majority of new development is targeting bajaux. Going forward, Tridium will be making many new tools and APIs targeting bajaux, much more than for bajaui.
Development on Hx views has basically ceased, with two exceptions. The Hx profiles themselves, such as HTML5 Hx Profile, are still fully supported. Also, HxPx will be receiving fixes to high-priority defects for the foreseeable future. New features or enhancements will land rarely, if ever.
If any of these statements are true:
bajauiYou should consider using bajaui.
If any of these statements are true:
You should consider using bajaux.