Field Guide · Maximo UI · Presentation XML

Maximo UI field guide: presentation XML on MAS 9, read from the product itself.

Every Maximo screen is one XML document. IBM last published a complete reference for that document in 2008 and nothing since covers what MAS changed. This guide reads the reference back out of the product itself, checked against MAS 9.2: the registry objects behind every Application Designer property sheet, the Designer's own dialogs, the domains behind every value list, and all 204 stock screens.

The reference IBM stopped publishing

IBM last described presentation XML control by control in 2008 and last printed its property tables in 2020. The Maximo Manage documentation for MAS 8.x and 9.x carries ten task topics as HTML pages, with no controls reference and nothing about what the Carbon-era interface changed for a customised screen. The product never lost the reference, though: Application Designer edits every control through a property sheet backed by a CTRL_* object in the data dictionary — its attributes are the properties, their titles the Designer labels, their domains the allowed values — and every stock screen is a row in MAXPRESENTATION. This guide reads all of that back from the product (54 registry objects, checked against the MAS 9.2 dictionary, the Designer presentation, 592 domains, 204 stock screens) and labels every line with the object or screen it came from.

How a screen gets on the page

Every application has one presentation.xml. IBM's install loads it into the MAXPRESENTATION table; Application Designer edits that same XML in memory and writes it back on Save. When a user opens the app the server pulls the XML into its cache, walks it tag by tag, asks each control's Java class for an HTML fragment shaped by the tag's attributes, assembles the page and sends it to the browser. That pipeline has not changed between 7.1 and 9.2: Carbon changed what each control renders, not how the document is read.

Anatomy of a presentation

The outermost tag is presentation, carrying the app id, its main object (mboname) and the application bean. One page holds the client area; the client area holds a tabgroup of tabs; a tab holds sections; a section can be split into sectionrow and sectioncol; the leaves are data controls — text boxes, multipart text boxes, combo boxes, check boxes, tables and their columns. Dialogs sit beside the page, and include pulls shared fragments from library.xml. Layout is relative, not pixel-based; order in the file is order on the screen; every control needs a unique id.

Controls, by family

The controls reference lists every control Application Designer registers and every framework tag the stock screens use — containers, data controls, actions, display, navigation, data sources, framework tags — with each property's type, label, value list and Designer tab, its stock usage, the containers it actually sits in, and a real example.

Binding data

dataattribute names the attribute a control shows; the object is the presentation's mboname unless a table, section or data source in between binds a different one. Reach a related object with RELATIONSHIP.ATTRIBUTE. inputmode sets default, readonly, required, query or password; lookup names a dialog id from lookups.xml; a multipart textbox pairs a key with a description via descdataattribute; defaults for new records come from a datasrc with defaultvalue children. A control without a label shows the attribute's title from the data dictionary.

Actions and security

Anything a user can do is a signature option granted to security groups; toolbar buttons and Select Action items reference one. Controls raise mxevents handled by bean classes named in beanclass. Menus live in menus.xml, which is edited by export and import, not in the Designer.

Conditional UI and the precedence rule

Data restrictions, signature options on controls and conditional properties in Application Designer make a screen behave differently per group. IBM states the precedence: database configuration first, data restrictions second, application configuration last. Hiding a field in the Designer is presentation, not security.

What changed under Carbon: 8.x → 9.0 → 9.1 → 9.2

The XML did not change; the rendering did. MAS 9.0 moved labels above fields, rendered YORN fields as toggles and moved table buttons above tables; 9.1 returned toggles to checkboxes, unified the left navigation and renamed the masthead class from .bx--header to .cds--header; 9.2 continues Carbon with layout controlled by mxe.webclient.* system properties. Custom skins and CSS are unsupported. These are practitioner-reported; confirm on your instance.

Bring your own export

Export a presentation from Application Designer, drop it on the playground, and it is parsed, drawn and checked the same way: ids, containment, documented properties, lookup ids, signature options and every bound attribute against the MAS 9.2 dictionary (or 9.1, if that's what you run). Nothing leaves your browser.

Moving screen changes between environments

Export/import moves a whole presentation. IBM's screen-upgrade kit — mxexport, mxdiff producing a transaction (.mxs), mxapply — moves only the deltas, so two teams editing the same screen stop clobbering each other. IBM ships the kit as Windows batch files only; a Linux build box runs them under the JVM directly.