Email: dev@concena.com       Twitter: @dbrucegrant

Entries with tag <em>nuxeo</em>.

Looking for Contract Nuxeo Developers

We are currently looking for a few contract Nuxeo DM and DAM developers to help out on a number of client and internal projects. Experience with IDE-based Nuxeo plugin development is a must. Experience with Google Web Toolkit would be beneficial but is not required. If you are interested, please submit your resume, rate expectations and contact information to bruce@concena.com.

Great resource for Nuxeo developers...

Whether you are starting out as a Nuxeo Developer or been working at it for years, the Nuxeo For Developers page is a great launch pad. Heck, even if you're not a Nuxeo developer, the resources for Maven and Git usage serve as great topical examples!

Comment on Nuxeo Tech Report 4 - DAM

Studio and UI configurability enhancements in Nuxeo DAM are welcome improvements. Making more of the interface more easily configurable with help more quickly meet customer requirements.

Unfortunately, I think Nuxeo has missed the mark when it comes to DAM performance. While DM has certain performance requirements, they pale in comparison to DAM. The average Nuxeo DM document (with attachments) is orders of magnitude smaller than a typically DAM asset. In this case I am talking about the use of DAM for high resolution images, graphics, and video.

There are challenges storing, rendering, and presenting all of these large files. Hardware (RAM, disk speed, CPU) is an extremely important part of the equation, but equally so are the underlying libraries that extract metadata, render lower resolution images, and stream video. Nuxeo's own code, wrapped around these libraries is also an important (and sometimes limiting) factor.

I believe that for Nuxeo DAM to be useful (in a marketing firm for example) there needs to be significant work on performance and scalability of DAM.

That's my two cents, albeit based though on real life experience with DAM. Anybody else have similar experience with DAM and handling of large digital assets?

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);
dataProviderAsync.addDataDisplay(getView().getDataGrid());
addColumnSortAsyncHandling();
 
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(), 
  CurrentSession.getInstance().getSessionId(), 
  CurrentUser.getInstance().getOwnerId(), searchFilter,  
  new AsyncCallback<ArrayList<LaborProfileRowFlat>>() {
 
@Override
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.
 
// MAKE THE CALL and PROCESS THE RESULT...
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.
 
// MAKE THE CALL
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) {
reqEntity.setChunked(false);
postMethod.setEntity(reqEntity);
postMethod.setHeader("Connection", "close");
 
HttpResponse response = null;
try {
response = client.execute(postMethod);
} catch (ClientProtocolException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
 
// PROCESS THE RESULT...
HttpEntity resEntity = response.getEntity();
return resEntity;
}
 
Straighforward enough once you have worked out all the details.
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!

Showing 1 - 5 of 35 results.
Items per Page 5
of 7

Recent Entries Recent Entries

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