Today we have a common question asked by sk90:, How can I attach files to documents through REST API?.

In his example, he uses our old REST API based on restlets. This API is deprecated and we now use Content Automation. Following are some examples for doing this.

Java Automation Client

This is an example using nuxeo-automation-client in a unit test. The test deploys a basic Nuxeo in a Jetty. Thanks to the EmbeddedAutomationServerFeature test feature, everything we need is deployed (core doc types, content automation etc…).

The first thing to do is create a File document at the root. Then we create a Blob with the automation-client API. Then comes the Blob.Attach request. Finally we test that the blob has been attached to the document.

PHP Automation Client

Here’s a sample taken from the nuxeo-automation-php-client repository. It lists the available workspaces and lets you choose a file …

Nowadays, single page HTML5 apps are becoming more and more common. In this world, there is a JavaScript framework developed by Google that caught our attention. In fact, there is no surprise here: at the last Devoxx conference, AngularJS was pretty much everywhere!

Here at Nuxeo we tried to use it for an internal application and in this post, I will explain how we did it and what choices we made.

A Development Workflow is Required

One of the strengths of AngularJS is its capacity to be tested. What we would like to find is a way to have the same Test Driven Development workflow when we develop in JavaScript. The good news is that some people already made some tools for this:

• Jasmine for testing
• Karma to automate tests
• Bower to fetch web packages
• Grunt to run tasks (like ant or make)

One team at Google made a very …

As you may perhaps know, VCS stands for Visible Content Store. It means that Nuxeo stores its documents in a SQL database, using a table for each schema or complex property type.

This enables various things:

• Put indices on some columns in order to tune some particular queries
• Access the tables to query data directly.

In this post, I will show you something else I did on a project in order to fill some data into a schema directly in SQL. I will use PostgreSQL for this example, but it should also work with other backends.

Querying nxp_log can be difficult

The problem here is to compute some statistics from the nxp_logs table that holds the data of the audit. Each row of the table holds the id of the document (log_doc_uuid), the category of the event (log_event_category) and the id of the event (log_event_id…

We’ve been working on a project using WebRatio to build a Web application that is integrated with the Nuxeo Platform to store documents. We wanted to share some insights gained from this project.

WebRatio Integration Overview

WebRatio is a Web application builder based on Eclipse. In this tool, you can define:

• Entities: Objects managed by the application
• Views
• Units: Links between Views with input, output and logic – a controller.

We decided to create a special Nuxeo unit linked directly to some operations or automation chains.

Here is the final application structure:

You can see that each box with a blue title defines a View, and boxes with a red title define a Unit.

We started to use a unit to execute Groovy scripts:

And finally, we created a special Nuxeo Unit that embeds the automation chain request:

And coupling management between the View and the Nuxeo Unit:

All works …

Keeping on with the extend Nuxeo Drive series, I’ll write about TopLevelFolderItemFactory. Just make sure you read the second post of the series first. The TopLevelFolderItemFactory is used to represent the Nuxeo Drive folder. Its default implementation displays the list of your synchronization root. This is the list of documents where you clicked on the sync icon. You can actually change this to display other things. You could, for instance, display the content of your personal workspace only. To do that we need a new TopLevelFolderItemFactory and the underlying adapter. Let’s get to it.

The New Top Level Item Factory

Instead of displaying all of the synchronized roots, we want to display the children of the user’s personal workspace. So we need to declare a new TopLevelFolderItemFactory. This is done, as usual, by contributing to an extension point. As there can be only one top level item factory, …

Hi everyone, and welcome to this new tech report. Today we have some news about Nuxeo Drive and Content Automation.

Nuxeo Drive

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.

To …

Building a wonderful content-centric application with a perfect taxonomy, with damn smart workflows, with incredible automation chains, etc. is great, sure. Still. You still need to paint it, if you see what I mean.

Nuxeo Studio lets you easily define the main branding of your application: login screen, colors used for text, background, links, … It is documented here. That said, you also often need to be more context-specific. For example, you may want to display a text widget in red so the user knows it is an important part of the layout. Or you may also want to force data entry with upper case letters for example.

Let’s take the following example: A workflow…

… has a “name” workflow variable. The form of its “First task” node displays this variable in a text widget…

… and you want it to be displayed in red.

So, you set its …