Email:       Twitter: @dbrucegrant
Integrating GWT Applications with Nuxeo

While support for GWT is baked into Nuxeo, this native approach doesn't offer the flexibility I'm after to create composite applications where Nuxeo is just one source/sink of content. In previous applications, I have used a rest-client based approach using the  RESTLET framework. However, I couldn't find any reasonable way to get the GWT datagrid control to play nicely using the restlet apporach. So, I switched gears, and returned to an HttpClient RPC approach for integrating GWT datagrids with Nuxeo.

What I do is bind the DataGrid to an AsyncDataProvider. The provider is set up in the corresponding presenter.

// Create a data provider.
dataProviderAsync = new LaborProfileAsyncDataProvider(SharedConstants.API_ACTION_LIST, eventBus);
The provider's onRangeChanged method then contains the applicable RPC server call. Data is reflected into the datagrid control in the onSuccess method (updateRowData and updateRowCount). OnSuccess also fires an event that has a listener update on screen statistics.
// RPC Call
rpcService.getLaborProfileList(action, CurrentUser.getInstance().getUserName(), 
  CurrentUser.getInstance().getOwnerId(), searchFilter,  
  new AsyncCallback<ArrayList<LaborProfileRowFlat>>() {
public void onSuccess(ArrayList<LaborProfileRowFlat> result) {
if (result != null) {
filteredRowCount = result.size();
if ("".equals(searchFilter)) {
totalRowCount = filteredRowCount;
updateRowData(0, result);
updateRowCount(filteredRowCount, true);
eventBus.fireEvent(new UpdateLaborProfileStatsEvent());
The rpcService class prepares the command url (in url) and the Nuxeo transaction (in jsonString), and then handles the resulting JSON. The URL corresponds to a defined URL restlet pattern in Nuxeo (still using restlets on the Nuxeo side), from example the pattern <urlPattern>/laborprofile/{action}</urlPattern> is mapped to the Nuxeo restlet class that handles laborprofile transactions. The URL is the glue between the GWT caller and Nuxeo.
HttpEntity resEntity = HttpClientCall.execute(url, jsonString);
String resSource = "";
JsonNode rootNode = null;
JsonNode dataNode = null;
if (resEntity != null) {
The actual HttpClient call requires a bit more packaging (call to set-up security is removed) but is relatively trivial.
DefaultHttpClient client = new DefaultHttpClient();
HttpPost postMethod = new HttpPost(url);
StringEntity reqEntity = null;
try {
reqEntity = new StringEntity(jsonString, "application/json", "UTF-8");
} catch (UnsupportedEncodingException e1) {
System.out.println("Error parsing jsonString");
if (reqEntity != null) {
postMethod.setHeader("Connection", "close");
HttpResponse response = null;
try {
response = client.execute(postMethod);
} catch (ClientProtocolException e) {
} catch (IOException e) {
HttpEntity resEntity = response.getEntity();
return resEntity;
Straighforward enough once you have worked out all the details.
Wearable Computers and the MYO #getmyo @thalmic

Wearable, guesture-based computing is a little off-topic from my normal blogging, but very cool and relevant (to me at least). Yesterday, Thalmic Labs, a Waterloo-based tech startup opened up pre-ordering for the MYO ( All the big tech blogs and publications covered the release and there are numerous articles about the MYO (Techcrunch, Wired, Financial Post). 

The MYO represents a big step into the future - guesture-based control without the need for cameras. The applications of the MYO are limitless.

For those that think this isn't real - think again. The science behind the MYO is real, the product is real, and those backing the company are very real (and experienced). I suppose I may be a little biased given that my son Aaron is one of the co-founders, however, I believe this technology has the potential to take wearable computers to the mainstream.

Nuxeo Upgrade 5.3.2 to 5.6

Once again I am impressed at the job Nuxeo has done to make the core migration process as painless as possible. Moving from 5.3.2 to 5.6 (through 5.4.1, 5.4.2, 5.5) is time-consuming but it produces a very predictable result. I think I read somewhere on the Nuxeo that this is the preferred approach, and it does make sense (at least to me). I create a bare-bones customization (schemas, doc types, UI, and a few other contributions) to enable me to load Nuxeo after each upgrade step and see that my data is preserved/available as expected.

Of course, that is not to say there isn't effort required in such a migration, especially when you've created extensive add-ons that rely on certain architecture/features/fields within Nuxeo. However, even that migration effort can be fairly easily scoped and understood.

My only real criticism of the process is migration documentation that explicitly spells out significant changes to the architecture or data model. Sorry, but trolling through java docs, changesets, or the like just doesn't cut it!

By way of example. From 5.4.1 to 5.4.2 the lock field (in the locks table) was removed and split into two separate fields (owner and created date). As part of the upgrade process Nuxeo is smart enough to split the existing field into the two new fields - unless of course it hits something unexepected and the process fails (so no lock information is preserved). Understanding what was happening and why took some time, which could have been avoided with a detailed change guide!

Time for NuxeoWorld North America

A number of  realizations got me to thinking that it's high time for a NuxeoWorld North America. Consider the following...

  • Recent Nuxeo press release about 40 percent growth in business in North America
  • Nuxeo CEO resides in the US
  • There are three offices in the US (and only one in Europe)
  • For what is effectively a one-day conference (not including the Dev day) the time and monetary costs are too high for many outside Europe to attend  

If Nuxeo is serious about growth, serious about feeding the community, serious about listening to customers, and wants to effectively compete with Alfresco and others then I think it's time to add NuxeoWorld part deux. Other vendors do exactly the same thing because they realize the importance of bringing clients, developments and vendors together face-to-face. Conferences help create and strengthen relationships, provide a forum for direct dissemination of important information, as well as gathering first hand real-world feedback.

I know there is a certain critical mass required before such an event can be considered, but certainly that point must be here (or at least very close).

Nuxeo Studio as a separately priced SAAS?

It's been a while since I have had any breathing room. I wish I had the cycles to attend NuxeoWorld in Paris, but I simply don't. However, when NuxeoWorld comes around it does get me to thinking about things Nuxeo could do better.

While I do most of my Nuxeo development in the IDE there are some tasks that are simply far more efficient in Studio (e.g., basic schema and document prototyping). The tool has definite value. Problem is, there isn't a separate offering just to use Studio - you have to buy a full support package (yes, there is Connect Base but that still has Nuxeo Maintenance wrapped in). As a developer and integrator this just doesn't make sense since I do not need or require technical support (that is included in the support package).

I would like to see Nuxeo sell Studio as a separately priced Software as a Service (SAAS) offering, much like Jira and many others. I think this approach would increase adoption and drive up customer support revenues.

I suspect many Nuxeo developers would be willing to pay a monthly usage fee -- especially if they have bought into the SAAS model.

Maybe this will be announced at NuxeoWorld, although that's probably just my hopeful thinking.

Showing 11 - 15 of 48 results.
Items per Page 5
of 10

Recent Entries Recent Entries

RSS (Opens New Window)
Showing 1 - 5 of 15 results.
of 3