Component library structure
Trinidad’s approach to web technology is comprehensive: Aimed at full control of all the bits and pieces that make up a web application, little should be left that needs to be added. So based on such a closed world, Trinidad presents itself with a wealth of components and tags that even include very basic XHTML tags as replacements for the real XHTML originals. This is no radical replacement approach, rather it enables Trinidad to remain in full control of mechanisms such as partial-page rendering (PPR, also generally known as Ajax) that otherwise would need to deal with potentially incompatible libraries externally.
The following image provides an outline of Trinidad’s structural package design:
Trinidad is divided into the following two namespaces:
- tr: It is the usual tag library id that references Trinidad’s core library tags. It’s a large library of over 100 components ranging from layout components and navigational components, to special viewer components that all implicitly support skinning, partial-page rendering, popup dialogs, error or info messaging, and so on.
- trh: It is the usual tag library id that references Trinidad’s XHTML support library tags, a small companion that offers alternatives for those XHTML tags that are usually applied to build XHTML structures, for example, XHTML tables.
Let us take a closer look at both namespaces. The upcoming image shows the core API’s hierarchical structure. The tags are backed by two types of Trinidad classes—UIX* classes that deal with the JSF component requirements to implement specific JSF lifecycle processing methods, and Core* classes that deal with the specific properties (getters or setters).
Trinidad’s XHTML tag library namespace (trh)
Two groups can be distinguished from the trh namespace. The first one deals with the definition of an XHTML page and provides the developer with the following tags:
- <trh:html>: It is used to define the whole XHTML page, analogous to <html>
- <trh:head>: It is used to define the header, analogous to <head>
- <trh:body>: It is used to define the main contents, analogous to <body>
- <trh:tableLayout>: It is used to define an XHTML table.
- <trh:rowLayout>: It is used to define an XHTML table line, analogous to <tr>; note that it can also be used to display an arbitrary line, particularly when elements need to be kept in one and the same line. Alternatively, it is particularly interesting to look at the tr namespace as it provides some less heavy structures free from table constructions, for instance panelGroupLayout with a layout set to vertical or a panelBorderLayout, both generating div structures instead.
- <trh:cellFormat>: It is used to define an XHTML table cell as part of an XHTML table.
The attributes of each tag are defined in a most consistent, and thus recognizable way. By the way, there are also tags for the construction of framesets such as trh:frame in case anyone still wants to make use of framesets.
However, before we deal with the attributes let us conclude this structural overview by a look at the organization of the functionality of the core tag library.
Trinidad’s core tag library namespace (tr)
The following groups can be functionally distinguished which is also reflected in the packages structure of Trinidad’s API (all beginning with org.apache.myfaces.trinidad.component; which has been left out here to avoid repetition). Note that, for completeness, we will also include information on the pure Java side as well as information on the few components that stem from the trh namespace:
- Basic document composition tags from the core API: document, stylesheet, form, subform. poll also appears here although it is not a composition tag.
- Form input and display tags, components from the core.input API: inputText, inputDate, inputListOfValues, and so on.
- Command or navigation tags from core.nav that includes two tag types:
- One that is focused on command tags that assumes a given form, presupposing the use of form and display tags from the foregoing group—commandButton, commandLink, goButton, goLink, and so on.
- The other deals exclusively with navigation: navigationTree, navigationPane, breadCrumbs, and so on.
- Large input and output component tags from core.data, for example, table, tree, and treeTable components.
- Layout component tags from core.layout, for example, all the swing-like panel tags, such as panelBorderLayout, panelHorizontalLayout, panelAccordion, showDetail, showDetailItem, and so on.
- Basic output components from core.output that are almost always used in a web application, for example, messages, outputText, outputLabel, spacer, statusIndicator, and so on.
- Model objects from core.model devised for various tags ; they provide the corresponding view models for their tag viewer counterparts, for example, SortableModel, CollectionModel and RowKeySet for tr:table, ChildPropertyTreeModel for tr:tree and ChartModel for tr:chart.
- A couple of converter components from trinidad.convert equip JSF and Trinidad input components with powerful JSF conversion, that is, convertNumber and convertDateTime.
- Validator components from trinidad.validator equip JSF and Trinidad input components with powerful JSF validation such as range validation (validateDateTimeRange) and validation by regular expression match (validateRegExp).
- Events and event listeners from trinidad.event add new event types and listeners specific for Trinidad components such as those that support Trinidad’s dialog framework, for example, commandButton to launch a popup dialogue using LaunchEvent, ReturnEvent, and ReturnListener. It provides only a few tags, but these can be very utile, for example, fileDownloadActionListener, resetActionListener, returnActionListener, and setActionListener.
There is a lot more to be found on the pure Java API side that either surfaces indirectly on the tag library as attributes, or is used implicitly by the tags themselves. Furthermore, there are utility classes and context support classes—RequestContext being probably the most prominent one because it offers a lot of functionality, for example, PPR from the server side.
The following figure illustrates the Java side of things (it shows what the structure of some of the classes behind core.input look like):
The preceding figure is an outline of the core.input API hierarchy. Again, we can see the typical UIX* and Core* structure.
Finally, let us take a closer look at the tag attributes.