Page Comparison

...

Potential Technical Hurdles

Use of $(document).ready

Most JavaScript

...

• Initialization
• Elision

...

-using Jasig portlets contain some sort of initialization methods that are called in a $(document).ready block. This initialization strategy does not appear to be compatible with jQuery mobile.

jQM recommends that such initialization tasks be performed via. However, code for these methods needs to be included before the import of the jQuery mobile javascript file.

Fluid Renderer

Using the Fluid renderer alongside of jQM appears to present some particular challenges. jQM parses the DOM to determine the roles of various elements, then adds additional divs, spans, and other wrappers, and applies CSS classes to both old and new elements. This process means that the markup originally included in the page is not the markup ultimately presented.

The Fluid renderer uses sample markup as a template for rendering data. In initial experiments, it appears possible to use the Fluid renderer alongside jQM as long as the Fluid renderer is initialized after jQM parses and enhances the DOM. Most renderer/pager code seems to work reasonably well with this approach, but we've identified several potential issues for some content.

Tab Index

jQM helpfully applies tabindex attributes to elements like navigation list elements. While this seems like a terrific accessibility enhancement, the Fluid renderer will use that initial markup as a template, eventually resulting in each member of the list having the same tabindex of zero. Mobile code using the renderer may need to manually apply the tabindex to each element.

Elision

Fluid's strategy for including a repeating section of two components involves using the "elision" syntax. For example, we might have:

<ul rsf:id="container">
    <div rsf:id="~repeatingNode:">
        <li rsf:id="part1">Part 1</li>
        <li rsf:id="part2">Part 2</li>
    </div>
<ul>

<ul rsf:id="container">
    <li>A: Part 1</li>
    <li>A: Part 2</li>
    <li>B: Part 1</li>
    <li>B: Part 2</li>
    <li>C: Part 1</li>
    <li>C: Part 2</li>
<ul>

While this syntax works quite well in the absence of jQM, we cannot rely on jQM to properly parse and enhance the above example. jQM is confused by the div wrapping the list elements, and simply refuses to render any contents for the list.

We can achieve moderate success by omitting data-role attributes from the markup and instead manually applying expected CSS classes. Some of the potential problems with this approach will be discussed later in the strategies section.

Incuding multiple versions of jQuery Mobile

uPortal currently take care to allow adopters to include multiple versions of jQuery in the same page. The uPortal theme, as well as each portlet, are expected to use jQuery in extreme noConflict mode, such that each portlet scopes its version of jQuery, as well as other libraries, to a single window-visible variable.

This strategy has been quite successful and has allowed uPortal adopters to freely mix and match portlets with various uPotal versions. If at all possible, uPortal would like to continue to allow adopters to upgrade uPortal and portlets independently of each other, and would like to avoid needing to maintain a separate view for each version of jQuery.

jQM may not be compatible with the approach described above. The markup parsing and enhancement can necessarily only be applied once to the page, and we don't yet know whether the library is otherwise compatible with using jQuery in extreme noConflict mode.

Theming

jQM has a somewhat different theme strategy from jQuery UI and other theming frameworks uPortal has used. Each jQuery theme contains a number of "swatches" (five in the default theme), which are ordered by visual importance. By default, the theme framework uses c as the baseline, a for important elements like headers and footers, and e for subtle accents. To style elements in the page, developers are instructed to place a "data-theme" attribute on the element or section to be styled differently from the default.

While the jQM themes are attractive and the system isn't difficult to use, the general strategy doesn't seem particularly ideal for portal use. All portlet developers would have to agree on the swatch letters to associate with various portlet components, and it might be difficult to achieve a standard look.

It might be wise for uPortal to attempt to do away with the swatch strategy, instead associating swatch colors with the portlet CSS names currently being donated to Fluid. For example, jQM recommends theming cancel and save buttons differently by using different swatches. uPortal might instead prefer to preserve the "primary" and "secondary" button CSS class names and associate swatch colors with those, since these CSS names are more semantic, easier to standardize on, and are already in use in uPortal. Similarly, we might prefer to re-use the portlet name CSS classes rather than using a non-default swatch level for portlet-specific navigation bars.

Navigation

Potential Strategies

Configure portlets to use portal's Javascript dependencies

...