Salient Soft

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 »

It is useful to be able to pass an enum rather than a string value as this introduces additional error checking by JSF.

JSF has a built in enum converter, so that all you need to do is pass a literal string which must then be one of the enum fields. JSF detects that the method argument is an enum and does the appropriate conversion and error checking. This will not occur until run time, but you will at the very least get a JSF error on your browser page and in the log, for example:-

javax.faces.el.EvaluationException: java.lang.IllegalArgumentException:
   No enum const class uk.co.salientsoft.view.Workspace$PageType.LOGOUT

See here for the StackOverflow post detailing this issue  – BalusC to the rescue again!

No Comments »

As I am running a Java development machine I want precise manual control of the versions of Java and all the related tools.

The Java auto updater runs regularly and nags about updating, but I want to turn it off. There is a control panel applet  – “Java (32-bit)” – with an option under the updates tab to do this, however it does not work – if you uncheck the “check for updates automatically” tick box, it appears to save OK but when you close and re-open the applet and look again the value has not changed.

This is due to an apparently long standing Java bug – it does not run with admin privileges and so cannot change the value. It would be nice if it gave an error telling you that it did not work due to a permissions problem, but unfortunately it just fails completely silently.

This post here outlines various solutions to the problem. The accepted answer, which worked for me, is to find javacpl.exe, right click it, and run with admin privileges. The location of it in my case was not where the post suggested, even though I had done a default install, so you will probably need to search for it. In my case I had a couple of versions of it, one was for an old version of Java. The path for mine which I used successfully was C:\Program Files (x86)\Java\jre6\bin

This fixed the problem, and upon reopening the control panel applet (with or without admin privileges) the box was unticked.

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 »

With JSF 2.0, it is now possible to use any class as an item in a selectOneMenu combo and related components. This is described in  “Core JavaserverFaces” p157ff. However, the book does not mention that you also need a custom JSF converter to convert between object and string.

If you then implement a custom converter as in the book on p279, e.g. with:-

<h:selectOneMenu styleClass="ss-tsw-select" id="cmbTheme"
      value="#{themeSwitcherBean.theme}" disabled="#{themeSwitcherBean.selectDisabled}"
      converter="uk.co.salientsoft.thememanager.ThemeConverter"
      immediate="true" onchange="submit()">

CDI fails to inject any references used in the converter class, as JSF 2 does not allow CDI in converters, as detailed in this Stack Overflow Post.

It does work however if you use an EL reference in the converter attribute as mentioned in this post here.

Note that the post indicates that it may require it to be an application scoped bean. In my case, it worked fine as both a request scoped and application scoped bean with no trouble. I also removed the @FacesConverter("uk.co.salientsoft.thememanager.Theme") annotation as this was no longer required due to the EL reference. The post indicates that this is perceived to be more untidy due to the use of EL and a managed bean, but I cannot see an issue with this. I cannot see why converters cannot be application scoped CDI beans, it all fits in fine. Here is the code fragment above, modified to use an EL reference instead:-

<h:selectOneMenu styleClass="ss-tsw-select" id="cmbTheme"
      value="#{themeSwitcherBean.theme}" disabled="#{themeSwitcherBean.selectDisabled}"
      converter="#{themeConverter}"
      immediate="true" onchange="submit()">

No Comments »

When developing plugin architectures with IOC, it is useful to be able to iterate over the available beans of a given type which are known to the IO container.

In CDI, this is easy to do, but it is not obvious how from the Weld documentation unless you do a bit of digging and searching.

This post here gives a sample application which does it. The crucial code snippet which does the business is here:-

private @Named @Produces ArrayList<String> wilsons = new ArrayList<String>();
@Inject
void initWilsonRacquets(@Any Instance<WilsonType> racquets) {
    for (WilsonType racquet : racquets) {
        wilsons.add(racquet.getWilsonRacquetType());
    }
}

The intance keyword (used with @Any) exposes an iterator which lets you iterate the available beans. In the above sample they are added to a collection, but you could equally call methods on them as you iterate if you don’t need to keep them.

The Weld documentation describes this on page 25, with the following sample fragment:-

@Inject
void initServices(@Any Instance<Service> services) {
    for (Service service: services) {
        service.init();
    }
}

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 »

This is an interesting  2 part article by Andy Gibson on how to use CDI conversations. Part 1 is here and Part 2 is here. Of particular interest is his discussion in part 2 about how to manage a collection of conversations and index them/return to them etc.

Another post here discusses the use of conversations and some custom reflection trickery to implement a generic CRUD application that only uses JSF view coding to implement a particular application.

No Comments »