Author Archives: Laurent Doguin
Hi everyone, and welcome to this new tech report. Today we have some news about Nuxeo Drive and Content Automation.
The first release of Drive is out and we did a quick review of the main tasks and main limitations that should be addressed in the next few weeks.
Identified issues / tasks
Adapter system: documentation and convergence
The Drive server side model is built on top of a pluggable adapter system so that mapping between file system items and document types can be configured.
The Adapter implementation:
- holds the logic for getBlob, delete, etc.
- hides the logic of differences between real documents and roots
The Adapter mapping system provides:
- per instance mapping since binding is not limited to doc types
- a complex adapter class hierarchy
This model is not simple and not easy to contribute, but we already had similar issues with similar modules (WSS / WebDav, …
As we’ve seen last week in the Extend Nuxeo Drive series, files and folders are represented server side using adapters. By default it’s the DocumentBackedFileItem adapter that is used for simple, non-folderish documents. When you get the file from a document, the document BlobHolder is used. It’s a document adapter used to get or set the main file of a document. It means that the file you see on the desktop while using Drive has been retrived with this code:
It also means that when you modify a file on the desktop, it’s updated to the document using the BlobHolder.setBlob method. Once you know that, you can do some interesting stuff without having to write Nuxeo Drive factories or adapters (sorry, not yet, maybe in the next post :-) ).
Here’s a fairly simple example. The book document type available in the BookTraining-Day3 studio template has no binary field, only …
Last week I started a series of blog post on how to extend Nuxeo Drive. Today I’ll write about factories and adapters. Every file or folder on the client file system is represented on the server side using adapters. Those adapters are associated to a particular document through a factory.
We can take the default configuration as an example to better understand this.
A look at the default configuration
Using Drive on the client side, the first entry point is the Nuxeo Drive folder. It contains all the documents you have synchronized. This folder is represented on the server side through the DefaultTopLevelFolderItem adapter, and returned by the DefaultTopLevelFolderItemFactory factory. This configuration is declared in the org.nuxeo.drive.service.FileSystemItemAdapterService#topLevelFolderItemFactory extension point:
As you can see, you can change the folderName parameter to something else. Some might prefer ‘My Drive’ or ‘My Nuxeo Files’ as name for your sync documents. The default implementation …
Like most parts of the Nuxeo Platform, we designed Nuxeo Drive as something extensible. And there are indeed different ways you can customize it to fit your needs. I’ll be writing more posts about how to extend Nuxeo Drive in the coming weeks. Today we’ll take a look at what you can do by simply overriding the different operations used by Nuxeo Drive.
Let’s take a very simple example. When Drive detects a conflict, the file is renamed a certain way. This is done using the NuxeoDrive.GenerateConflictedItemName operation. So what we can do is override this operation to specify our own way of renaming a file. Right now what it does is split the name of the file and the extension. Then we generate the contextSection. It’s the user’s first and last name concatenated with the current date formatted as “yyyy-MM-dd hh-mm”. Then it puts them back together.
Here’s a question that comes back often, asked by bruce: How to add tag capability during drag’n’drop?. Since Thierry added HTML5 drag’n’drop to the Nuxeo Platform, it’s possible to fill in metadata right after the import, and apply them to all the imported documents. But I understand it can be frustrating not being able to add tags. And fortunately the drag’n’drop service for content capture is extensible. The full code sample is available on GitHub.
So here’s how it works. When dragging files in a content view for at least 2 seconds, you’ll be prompted with a Select import operation choice. Those select operations are actually actions. It means you can add as any as you want through the action extension point. These actions have a specific behavior.
The ID of the action must, for instance, be the ID of the operation or the operation chain that …
Being big Atlassian fans here at Nuxeo, we recently started using HipChat. It’s an enterprise chat room. One of the cool things about HipChat is its very simple web API. It makes it really easy to send notifications to a chat room.
To show you how dead easy it is, I did a project showing how to send Nuxeo events to a Hipchat room using their web API. I did it using Nuxeo IDE to generate my plugin structure, using the Nuxeo Plugin Project and Nuxeo Listener wizards. My listener only listens to documentCreated and documentModified events. Each time they occur, we send a small message to a HipChat room, containing the URL of the document, its title, date and creator. The code is really simple (especially because most of it is generated by Nuxeo IDE):
What it does is simply relay the modify or create events to a room. …
There’s an interesting question today from milonette, asking how to access labels with MVEL. Sometimes the Content Automation API doesn’t provide everything you need out of the box, hence the question. But the good news is this API is extensible.
While some functions are already available in the automation context, there is currently nothing to access the resource bundles. We’ll need to add our own function into it. This is quite easy to do. First we need to write the new function we need, then we’ll write an operation that adds this function to the content automation context.
Our localized function needs different parameters. We want the locale, the name of the resource bundle, the key of our message and some optional parameters. Here’s a simple implementation:
Now that I have my function, I need to create an operation that will make this available within the automation context:…
Hi everyone, and welcome to this new tech report. It’s a rather short one this week — we’re mostly consolidating what you’ve read about in the previous report. Oh, and we released Nuxeo Drive :D
Drive 1.0.1 released
Drive 1.0.1 was release last week.
There is a known issue when several files are created on the server: because the server may be busy, there is a time shift between the audit log event date and the time where the audit entry is actually persisted. This time shift can lead the client to ‘loose some events’ and then not see some files.
To fix that, we should:
- Review the polling system: based on the audit sequence ID rather than the time window
- Prepare the upgrade of the client side database
- Make the client able to detect when a database update is needed.
There is a …
Today we meet Sylvain Chambon, head of the Java Integration Division at Open Wide, and contributor of the Kerberos authentication plugin. You have probably heard of Nuxeo partner Open Wide already, as we did a webinar together about the EasySOA research project. I had the opportunity to interview him at the Documation conference where he gave a standing-room only presentation about how he used the Nuxeo Platform to build a project management app. The good news is that he will give this presentation again as a webinar on April 24th.
The audio is available, with the background noise of a very busy Documation trade show.
Hi Sylvain. You’re working for a systems integrator called Open Wide. Are you working in the Enterprise Content Management field specifically?
Actually I’m working in the Java integration unit, across domains. We’re organized by technology. I …
The tag service uses two important concepts: a tag object, and a tagging action. Both are represented as Nuxeo documents.
A tag is a document type representing the tag itself (but not its association to specific documents). It contains the usual dublincore schema, and in addition has a specific tag schema containing a tag:label string field.
A tagging is a relation type representing the action of tagging a given document with a tag. (A relation type is a document type extending the default relation document type; it works like a normal document type except that it’s not found by NXQL queries on document). The important fields of a tagging document are relation:source which is the document ID, relation:target which is the tag ID, and dc:creator which is the user doing the