Inconsistent CMIS Query Results? It’s not You, It’s your Locale.

A simple CMIS query like:

SELECT D.* FROM cmis:document AS D WHERE D.cmis:name LIKE '%Flower%' OR D.cmis:contentStreamFileName LIKE '%Flower%'

was giving me a fit lately, not working at all in RightsPro‘s CMIS plugin which uses OpenCMIS and yielding inconsistent results in CMIS Workbench where re-posting the same query ten times would give the expected result maybe half the time.

Thanks to Florian Müller and this post, it seems as though Alfresco doesn’t always behave as expected when the locale is set in the CMIS session.

Removing the locale session parameters got things working in RightsPro, but I didn’t immediately see an easy way to change the locale in a Workbench session (the log shows that it’s using a default of en_US), and I still don’t know what’s up with the inconsistent results there, perhaps a coincidental caching issue.

This was all using OpenCMIS 0.3 against Alfresco Enterprise 3.3.1 over SSL.

MyFaces Tomahawk and the HTML BASE Tag

This one incited a bit of facepalm.

When trying to changing part of RightsPro‘s header implementation to use the HTML BASE tag the element seemed to be ignored completely and resource references were still relative to the page URL. The tag was present, correct, and closed, but having no affect.

It turns out the BASE tag must appear ‘before any element that refers to an external source’ but MyFaces Tomahawk adds any script references needed immediately after the opening HEAD tag, rendering the BASE tag useless.

I don’t have time to modify the Tomahawk source at the moment for a proper fix but did submit a bug.

As a workaround you can put the BASE tag above the head element. It’s not valid HTML but most browsers will still obey it and render the page properly.

A short post, but it may save a few precious hairs from being pulled out. I’ll update if and when the bug is resolved.

Growing jQuery Progress Bars

At RightsPro, we’ve chosen to go with jQuery UI as an interface framework and while the progress bars look great out of the box we wanted to add the effect of the progress growing to its value when the user visits the page to draw attention to it.

jQuery’s documentation for the UI components, including the progress bar, is straight forward.

Once you’ve included the proper javascript files and created the progress div a simple javascript command adds the appropriate classes and creates the progress bar:



$(function() {

$("#progressbar").progressbar({

value: 37

});

});

but to add the growing animation effect we initially set the value to 0 then animate the width of the progress bar value div created by jQuery’s javascript:



$(function() {

$("#progressbar").progressbar({

value: 0

});

$("#progressbar > .ui-progressbar-value").animate({

width: "37%"

}, 500);

});

where 500 is the time the animation should take in milliseconds.

This gives the desired effect of the progress bar growing to its value when the page loads rather than immediately rendering the final result.

Not earth-shattering, but a nice little trick.