Access content instances in JSF

In a product detail page (web/productDetails.xhtml), we show all fields of the selected product instance (stored in #{productBean.pk}) using the <fx:content> tag and provide a JSF link to the manufacturer's page. The content instance values can be accessed directly through a JSF-EL variable. For example, #{product.name} returns the name property of the currently shown product:

The product's manufacturer is a referential property, i.e., it references another content instance. To access the manufacturer's values, we dereference the manufacturer using a $ suffix, i.e. #{product.manufacturer$.name}. We also create a command link to open the manufacturer's page. #{product.manufacturer.defaultTranslation} returns the default (and in this case, only) translation of the manufacturer reference, a primary key object:

Rendering the images stored with a customer is also a simple task. The product's image property stores references to the binary (not the binary itself, since it would waste way too much memory), which can be rendered as an image using the <fx:thumbnail> tag. The $list suffix provides an iterator over all values of a property or group with a multiplicity greater than 1:

The final feature of the product page is the handling of the product's variant group. For each product variant (i.e., the base product with a color association), we render the article number, the color and a link to update the current article number (in the full products page, the variant's images will be added to the common product images):

Run It!

If you have already installed your application server and defined the data sources as described in the installation guide, the project can be compiled and deployed. To do so, execute

ant

in the products directory. If all works out as planned, you will have a file called products.ear in the dist subdirectory - ready to be installed on your application server.

Content Versions, Workflows, and the Live Version

[fleXive] contents are versioned: when a content is edited, the user can choose to create a new version instead of modifying the existing one. Workflows provide a way of describing organizational structures for the users of an application: for example, a newspaper article may go through the workflow steps editing, review, and reviewed. Different users have different responsibilities, for example the article author may not change his own article from review to reviewed, while a reviewer cannot change an article while it's in the editing workflow step.

The live version indicates the version of a content that the actual application user may see. This might be the latest version, but could also be an archived version due to recent editing of the content. To make a content version the live version, you have to set it to the special workflow step Live. Only one version of any content instance can use this workflow step, so there is at most one live version of any given content.

You can see this concept in action in the product application: edit an existing product in the backend, change the workflow step from live to edit, and it will disappear from the front-end application. Or create a new version in the edit step, make some changes, and the front-end data will still be served from the live version until you set the new version to live.

Outlook

This article showcased some of [fleXive]'s major features: complex data structures, multi-linguality, versioning, and workflows. There are many more features left unexplained - for example the highly optimized content tree, providing a generic, hierarchical storage for tree nodes, the fine-grained security system down to individual properties based on ACL's (access control lists) and usergroups, or the scripting and document management facilities (like EXIF extraction from images and full-text indexing of PDF files). For more information on those features and much more, stay tuned for more articles and visit http://www.flexive.org, especially the extensive reference documentation.

Markus Plesser
CTO and software architect at Vienna/Austria-based software developer UCS - unique computing solutions gmbh. He is one of the lead developers of [fleXive] and amongst other things responsible for the persistence engine. While interested in web technologies he prefers the server side of applications - namely EJB, Spring, etc.

Daniel Lichtenberger
is a software engineer at Vienna/Austria-based software developer UCS - unique computing solutions gmbh. He develops enterprise software for the Java EE platform and has a keen interest in web technologies and agile development.