Salient Soft

This is a tricky issue to control correctly. The following points have been found during testing (Mojarra 2.0.4 FCS / Primefaces 2.2.1 / Glassfish 3.0.1)

1. One key issue is that to start a new conversation on a page, the navigation to that page must not propagate any previously active conversation. This will then start a new transient (i.e. not long-running/not started) conversation on the new page, and conversation.begin() can be used to make it long-running (i.e. start it).
2. When doing a standard JSF Ajax postback, the current conversation is always propagated, and it does not appear to be possible to prevent this/start a new conversation from a postback. JSF always adds the current CID as a querystring parameter
3. To prevent propagation and to allow a new page to start a new conversation, GET navigation needs to be performed. This fits in well with my main toolbar options – I use pre-emptive GET navigation for the main pages with full page refreshes.
4. Primefaces p:button allows the new JSF 2 outcome style GET navigation but cannot be stopped from propagating a conversation – it always adds a CID parameter. If you add one with an empty or null value, you still get a “cid=” attribute which CDI then spits out as an invalid conversation on the new page.
5. h:link can be stopped from propagating by using an explicit f:param for the cid, providing the param has no value or an explicit null value (an empty string will not work).
6. Trying to refer to another inactive conversation, e.g. by storing conversation scoped bean references in a session level map and looking them up, seriously screws up CDI with an extremely long/possibly recursive stack trace. (See Mantis issue xxx for the stack dump). This is likely to be due to the proxying mechanism used for conversations.
7. Therefore, it is not possible to invent say a ‘onPageLeave’ event for a previous page and call it after a new page has started and had its conversation activated.
8. If therefore I need to refresh all pages for the application, for example if an OptimisticLockException occurred, I use a central workspace session bean to manage all the pages. I set a refresh pending flag in a map for each page, and then when the page is next visited, the workspace bean calls a refresh event of my own for the page, and then clears the pending flag. When processing the current page after an OptimisticLockException, I can refresh directly if the user requests it from a lock dialog.
9. My workspace bean holds the CID for each page against the page name in a map, and uses this when rendering the Toolbar, adding the appropriate cid= parameter for each toolbar option. In fact I use an outer map keyed on page group name (where the page group corresponds to a top level toolbar option), with an inner map containing all the cids and refresh pending flags for the individual pages in that group. This allows for example a report toolbar option to be a menu of currently active reports, and allows new reports to be created dynamically as new conversations and added to the list under the report menu on the toolbar.
10. Conversations are started and ended via calls to the workspace bean, which can then add/remove entries from the maps to keep track of what pages/cids are currently active.
11. Regarding navigation and cid propagation, another option is to call JSF directly to obtain the navigation case for an outcome. ConfigurableNavigationHandler allows you to pass an outcome and get the actual navigation case, from which you can then get the URL. This should allow full control of the cid= propagation parameter on the querystring, and allow control for components which do not support JSF 2.0 style GET pre-emptive navigation directly from an outcome. The url can be passed to any component which accepts a url, and should then still perform the correct navigation and conversation control. See CoreJSF 3 page 333 for a code example on this. This method could prove useful for example with a Primefaces MenuItem, which does either JSF postback style navigation, or URL navigation, but does not directly do pre-emptive GET navigation by giving it an outcome.

No Comments »

It appears that there are widgets and themes which do this, and which allow dynamic theme switching of the jQuery themes. The attraction of this is that it would allow closer integration of the look and feel when using a JSF/Primefaces Java based web app called from an enclosing WordPress based site. One interesting possibility would be to tie the theme selection used for the WordPress site in with the theme selection for the Primefaces based web app.

This will need more investigation but as a starter here are a few interesting links found from initial searches :-

• http://www.google.co.uk/#q=Wordpress+jQuery+themes+switching&hl=en
• http://wijmo.com/wordpress-wijmo-theme/
• http://www.1stwebdesigner.com/freebies/wordpress-theme-jquery-and-ajax/
• http://wpswitch.com/blog/10-tutorials-using-wordpress-and-jquery/
• http://net.tutsplus.com/tutorials/javascript-ajax/jquery-style-switcher/
• http://www.net-kit.com/10-practical-jquery-style-switchers/

No Comments »

I hit this issue when displaying email addresses in a p:dataTable.

The problem is that for long strings without spaces, the browser tries to enlarge the table cell width, causing the table to stretch beyond the correct bounds and messing up the layout. A column will wrap and enlarge vertically, but this will only be done when it can break on a space. Setting the widths for the columns is technically just advisory on the browser and may be overriden if needed.

There are various solutions to this, and this post here in Stack Overflow discusses them.

My chosen solution in this case was the following:-

• Place the text in the cells in <spans>, to allow them to be styled with CSS. You could also style the column <td> cells by applying style/styleClass attributes to the p:column tag, but this will limit your flexibility – for example if you do this p:column does not expose the title attribute on the <td> (see below)
• Style the <spans>  with display:inline-block;overflow:hidden. This allows a width to be set for the span (I used the same width as set for the column), and hides any overflow (which would otherwise bleed into the next column).
• Text will still wrap on spaces if they are present, but long strings without spaces, such as email addresses or file paths, do not cause a problem, but they will truncate and so will not be fully visible by default.
• I include a title attribute on the span to include the full text. This allows the full text to be displayed on hover for any long strings that are truncated in the cell.

This neatly solves the problem, and prevents the table layout messing up.

No Comments »

This issue was encountered under Primefaces 2.2.1 – other versions have not been tested for this. In certain cases it is possible for the panel component to not render the title bar at all.

When this happens, the content is rendered assuming the panel is expanded, but the panel bar itself does not render, and crucially, there is therefore no access to the expand/collapse icon as it is not rendered. Other components can expand/collapse the panel via its widget however.

This is caused when there is neither a header attribute present nor a header facet present. If one or other (or both) are present, the panel title bar does render. Note that the behaviour occurs even if toggleable is set to true.

This behaviour is undocumented and is rather a gotcha when you hit it, as it seems indicative of something more serious.

The solution is straightforward however – you must provide either the header attribute or a header facet in order for the panel component itself to render correctly.

No Comments »

This post details some tips discovered whilst experimenting with p:panel.

1/ The toggle button on the right hand side of the panel is rendered with ui-state-default. This does not look attractive with some themes – it often looks like a bit of a zit due to the background on the thick plus sign icon. I noticed that the dialog component p:dialog does not render its close icon in the header with ui-state-default,  and this looks much more attractive as the surrounding highlight on the icon only shows on hover.

This can be applied to p:panel by removing the ui-state-default class from the anchor tags around the icons on the panel header. The following example jQuery performs this (in my case, the panelDivId argument is the ID of an h:paneGroup/div surrounding the panel:-

function ss_PanelFixIcons(panelDivId) {
    var escapedPanelDivId = panelDivId.replace(/:/g, ‘\\3A ‘);
    var panelIcons = jQuery(‘div#’ + escapedPanelDivId + ‘ div.ui-panel-titlebar > a.ui-panel-titlebar-icon’);
    panelIcons.removeClass(‘ui-state-default’);
}

2/ It would be nice to be able to explicitly expand and collapse the panel as well as to just toggle it. In fact the panel widget does expose its current state via its cfg property, although this is not publicly documented. The following example functions use this to provide explict expand, collapse, and set to passed boolean state functions. In addition a function is provided to get the current panel state:-

function ss_PanelExpand(widgetVar) {
    if (widgetVar.cfg.collapsed) {
        widgetVar.toggle();
    }
}

function ss_PanelCollapse(widgetVar) {
    if (!widgetVar.cfg.collapsed) {
        widgetVar.toggle();
    }
}

function ss_PanelSetCollapsed(widgetVar, state) {
    if (!widgetVar.cfg.collapsed == state) {
        widgetVar.toggle();
    }   
}

function ss_PanelGetCollapsed(widgetVar) {
    return widgetVar.cfg.collapsed;
}

3/ A query came up on the Primefaces forum on how to lazy load the panel, as it eagerly loads and the expand/collapse is all done client side. The post is available here. the solution is straightforward:-

• Use a toggleListener to update a renderPanel property to true if the panel state from the event was visible, and false if it was hidden.
• Then conditionally render a content h:panelGroup inside the panel, using the above property as the rendered property.
• One issue with this is that the actual panel toggle occurs before the ajax update of the panel not after, so with the slide toggle effect on (say with toggleSpeed=”1000”), you see an empty sliding toggle first, then a non sliding ajax update. In this case it is best to turn off the slide effect with toggleSpeed=”0”. If you use another button to toggle the panel you can get around this, as the onComplete event for the button can toggle the panel (via its widget/ as per the above JavaScript), and this happens after the Ajax to render the panel. In practice you would have to somehow overlay the standard toggle button with another one of your own, or manually disable the standard one via CSS, as if you set toggleable=”false” for the panel this completely disables toggling via the widget as well as removing the toggle button.
• It is probably not worth the trouble of trying to get sliding to work if you are lazy loading. Note that when I tried some older/slow machines the slide effect rendered poorly anyway, so this should also be born in mind.

No Comments »

There appears to be an issue when using EL in child components included in a composite component using <composite:insertChildren>

I am already using this technique for the tableCC component, to insert the columns as children, and the child columns have plenty of EL in them which is not passed to tableCC, as well as having custom tags as columns. However, there appears to be an issue when this technique is used in nested composite components.

When I tried this, I found that any EL expressions in the child components is evaluated as late as possible in the context of the called composite component, not the caller!

This means that if you need to refer to an attribute passed in to the caller of the CC, you must pass that attribute on to the CC as well as referring to it in the child components, as their EL will be evaluated in the CC not the caller.

Providing you do this, it all works fine. However, the issue with this is that it will tend to break encapsulation of the interface to the child nested CC – you have to change its interface depending on what EL you want to use in the child components passed to it.

This was unacceptable to me, so I switched to a different technique. Instead, my base component (actually a flexible icon/base button using p:commandLink) became a custom tag, and I used facelets <ui:inserts> to handle the insertion of custom markup. I then wrapped composite components around this to provide the necessary custom markup.

The reason for going down this route was that I have had issues with glitchy ajax updates on standard Primefaces buttons at small sizes (see this Mantis issue). Also I was crafting icon buttons with multiple jQuery icons on them, using CSS to position them accurately. This was tricky with a p:commandButton and involved introducing CSS that I was concerned may need change in future releases, so I went my own way when using highly custom buttons and buttons at small sizes.

No Comments »

This can be done e.g. by a Facelets Decorator using <ui:insert> and I have used this in a number of places.

However, in one case, I wanted to make a complex treeBrowser custom tag switchable between editable mode and readonly using just a single flag passed as an attribute. Note that I did not want to switch it dynamically at run time – I just re-used the tag in a number of places and some were editable and some were not. As this switch involved a number of changes in the tag, it was convenient to drive them all from a single flag.

In addition, whilst I could have used a decorator for this, I already had 2 versions of the tag each decorating a base version, where each version was used to browse completely different tree structured data in the application which was all handled polymorphically.  Using decorators for readonly/editable as well would have multiplied up the variants to 4, which was undesirable. By using a single EL flag, I was able to make all the switching entirely in the base custom tag which was a real help here.

Anyway – to discuss the real point of the post – to achieve my goal I needed to conditionally include columns for a <p:dataTable>. Using <ui:fragment> to do this does not work as <ui:fragment> creates a new component in the JSF tree which is not a column, and <p:dataTable> ignores any children that are not columns. Whilst there are ways using composite components to indicate with interface properties the precise Class type that the component appears to be, fooling <p:dataTable> by making it look like a column does not work – I tried this and it failed, and there are posts on the Primefaces forum citing the same issue.

The simple solution was to use <c:if> to conditionally include columns. This eventually worked correctly, once I had fixed a particularly nasty incorrect JSTL namespace issue which is fully described in this post here.

No Comments »

Primefaces uses the theming capability of jQuery, including the ability to create your own themes using ThemeRoller. This powerful facility separates theme specific CSS from structural CSS which defines the layout of UI components such as tables. At the time of writing, Primefaces has 32 different themes. It does also have a themeSwitcher component, but this has some issues which make it less than ideal for many environments. In addition, the structure of the themes has changed as of version 2.2 – they are now deployed in jars rather than as bare resource files. The following lists the salient issues and desirable features regarding the theme switcher:-

• When switching themes, rather than using a theme deployed with the application, the Primefaces themeSwitcher downloads the new theme from the internet and installs it directly, which is undesirable in many environments.
• Ideally, as well as using the themes deployed with the application, the themeSwitcher should be configurable dynamically to allow new themes to be easily added.
• The theme switcher should also, as far as possible, derive its theme list presented to the user dynamically from the themes that have actually been deployed. Failing this, it should be possible to configure this list as a deployment configuration option, i.e. in web.xml
• It would be desirable to isolate the theme Switcher from any further changes to the Primefaces theming structure. For example, if a plug-in architecture is used, a new theming interface can be incorporated simply by adding a new plug-in.

The Theme Manager attempts to address all of the above issues to provide a flexible and upgradeable solution to Primefaces theming. The Theme Manager including PDF documentation will be found  in the repository here.

No Comments »

This utility was developed to allow JSF and Java software to dynamically manage dependency issues caused by interface changes across differing versions of dependant libraries, by querying the utility at runtime with rule based match checks about the versions actually deployed. Typically interfaces to software are consistent for a range of versions, and then change whereupon they remain the same for a further range of versions. The Version
Manager thus allows rule based checks to match a contiguous range of versions, as well as matching a single specific version.

The utility was developed in response to issues caused by changes between Primefaces versions. A particular case in point was that some custom Javascript and CSS was implemented for V2.2.M1 to fix common issues concerning header alignment and column width for scrolling tables. These changes were encapsulated in .css and js files in a TableCC composite component which decorates the standard Primefaces p:dataTable.
These fixes of necessity used css and jQuery selectors referring to underlying Primefaces structural css classes – this exposes such code to risk of change, but in this case the risk was justified as the code was there to fix issues.

The css in Primefaces changed late on in the V2.2 cycle – the class names changed and the HTML was simplified to remove a div container layer. These changes broke the above code. It was felt that this would in general not be an isolated issue. Primefaces is a fast moving development project, which has its upsides in that new features and new versions come onstream regularly. The downside in a fast moving environment can be issues such as the
above one. In fairness to Primefaces, it is very difficult to develop a generic Table component using current HTML standards which allows fixed column headers with a scrolling data table. Some things such as dynamic resizing of columns just cannot play ball in the current scenario, and scroll bars coming and going with different data volumes add further challenges of their own! In practice it is not possible to cover every possible use case. My approach is to narrow down a particular set of use cases I need to work with, and then come up with the necessary fixes/decorator components as above to handle those particular use cases.

In order to mitigate the effect of this kind of issue when versions change, and to avoid proliferation of a number of different code versions each matched to a set of dependant library (e.g. Primefaces) versions, a Version  Manager facility was developed.

The Version Manager including PDF documentation and an example may be found in the repository here.

No Comments »

This is a set of loosely related posts which are of interest.

• This post here on the Primefaces forum discusses partial Page update with view Expiry error handling using a generic Global Exception Handler. The idea can handle different scenarios generically, e.g. Ajax or not, and seems to have impressed Cagatay Civici so well worth a look!
• This post on Stack Overflow discusses the desire for navigation during Partial Page Update. The simple conclusion is that basically you can’t, so don’t try it! This implies that if you code an application that uses PPU across a number of forms/conversations, then it all must be driven from a single URL.
• Another important point which reinforces this is made on Primefaces FAQ #4, which states that forward navigation in Primefaces does not currently work with Ajax, although this may change at some point in the future.

No Comments »