nuxeo • Themes

The changes described in the previous articles (New CSS property editor and Redesigned fragment factory) have been checked in and should soon be available in the latest nuxeo DM snapshots.

Screencast showing the new CSS editor

The CSS property editor is getting a usability overhaul. In its current form it consists of:

• 2 edit mode buttons (CSS / FORM)
• a drop-down list of CSS selectors (h1, a:hover, form input, …)
• a group of  style category buttons (all, color, background, border, font, image)
• the actual input fields for setting CSS properties
• a style picker

CSS property editor (before)

Because of the long list of properties the UI requires a lot of scrolling.

The category buttons are not very useful because they target the wrong elements, for example to change the color of a font it seems more intuitive to go to the Font section than to the Color section. The Image category begs the question: the image of what?

So what are the changes?

• we use the Tahoma font for better readibility
• property names are right-aligned to better match labels and input fields
• we use a more neutral style picker icon
  
• we show already set properties first to minimize the need for scrolling
• we introduce new style categories: backgrounds, borders, font, text, visual, …
• we use an accordion layout (+/-) to display categories and properties

CSS property editor (after)

A word about CSS3

The compatibility level is CSS 2.1 by default.

But since newer generations of web browsers are beginning to support CSS level 3, a CSS3 button is added to get access to visual features such as:

• box-shadow
• text-shadow
• border-radius
• border-image

The first release candidate of Prototype 1.7 was released a week ago.

It contains some interesting new features:

• the integration of a new CSS selector engine (Sizzle) with much improved performance compared with Prototype’s own engine (see performance tests)
• a more concise API for handling events (Element#on)
• a measure tape for computing layout dimensions (Element.Layout)
• an ECMAScript 5 compliant JSON implementation

The first live tests show so far no particular compatibility issues with the theme editor, except for the form data which isn’t serialized as expected.

This is easily fixed by replacing:

    formMap.toJSON()

which now according to the ES5 specification has to return an object, with:

    Object.toJSON(formMap)

which returns a string.

The fragment factory is used to insert page fragments into a theme (by clicking on Add fragment via the contextual menu).

>>> Take a look at the screencast

The operation is done in four steps:

1. Selecting a fragment type (data)
2. Selecting a view (HTML)
3. Selecting a style (CSS code)
4. Reviewing the selection and adding the fragment

Each step determines the range of choices available in the following steps.

Fragments are responsible for generating data according to a data model (menu, feed, region, navigation, …). For any given type of data model, a limited list of views is available.

The views are responsible for converting the fragment data into HTML code. For example a list of links may be represented as a vertical menu or as a horizontal trail, or as news ticker…

Since views expect a given type of data format, they know in advance how to interpret the data. There is so to speak a strong typing between fragments and views.

A special type of fragment called the generic fragment generates no data at all, which means that views are responsible for obtaining the data directly from the application.

In this example we select the search box view:

Here is the HTML code of the search box:

<form action="${Root.getPath()}/@search" method="get">
  <div>
    <input type="text" name="fullText" value="" />
  </div>
</form>

In the third step we can choose to apply a style to the selected view. This is an optional step.

The CSS code of the search box style is:

form {
 background-color: "light blue (Chalmers ST colors)";
 border: 1px solid "white (Chalmers ST colors)";
 margin: 18px 15px;
 padding: 8px;
 text-align: left;
}

form input {
 background: "search (Chalmers ST backgrounds)";
 border-color: "dark blue (Chalmers ST colors)";
 border-style: solid;
 border-width: 1px;
 color: "dark gray (Chalmers ST colors)";
 font-size: 12px;
 padding: 4px 20px;
 width: 120px;
}

It is clear that not all styles are designed for the search box view. The typing between views and styles is weak and there is no guarantee that styles will match any given view.

Finally we review the selection. A preview is generated on-the-fly and by clicking on the ADD FRAGMENT button we can insert the fragment into the theme. This operation, as all other theme operations, can be undone by clicking on undo add fragment.

Screencast showing the four steps

Improvements

There is no way to know in advance how well styles and views will match one another. A solution would be to restrict the list of styles that can be applied to a view. In that case when a style is created or being edited there should be an option where to specify a list of compatible views. If no view is selected one could assume that the style applies to any view.