Welcome to the August tech report. This month we have updates on our UI/UX Framework and Content Automation.


UI/UX Framework

New Widgets

Select2 Integration

Guillaume took over the integration of Select2 based widgets. We will have 6 widget types:

  • suggestDocument: single/multi

  • suggestDirectory: single/multi

    • Built-in support for nested vocabularies

  • suggestUser

  • suggestGroup

These widgets will be integrated as a new nuxeo-jsf module in 5.7.3. Select2 widgets will be used inside the default screens:

  • Metadata layout with Nature/Subject/Coverage

  • Faceted search

  • Relation screen

Part of the goal of this set of Select2 widgets is also to fix the problem we have with the current suggestion and chained vocabularies widgets. Anahide and Guillaume will create the Jira issues about all problematic use cases:

  • Integrate use case in Layout Demo

  • Update widgets and Studio

Anyway, even if the use cases are complicated, we need as much as possible to keep the meta-model simple.

Note: It is probably better to leverage the fact that users can override JS rendering callbacks, rather that creating widgets with 23 properties.


Playing with Select2, we discovered that SafeEdit is not generic enough to also handle the case of Select2. Guillaume will extend the SafeEdit JS API so Select2 widgets can register themselves.


We now have in a sandbox a simple integration of jQueryFileUpload with Automation API that can be used to replace the import file dialog. Switching from RichFaces upload to jQueryUpload provides:

  • Client side progress management on recent browsers (not MSIE 7,8,9)

  • Upload outside of Seam context (no more Concurrent calls to conversation)

  • Skinable UI

  • Drag&Drop support

  • Plugins to manage file preview

The sandbox module has been realigned to 5.7.3 and the goal is now to integrate it by default:

  • Replace the import file fancybox dialog

  • Replace the files tab

Ideally, we'll also want to package it as a real widget and use it to replace the file widgets.

Seam Injections

As discussed earlier, we have started building our own version of Seam: NXP-12207

For now, our branch was started from 2.1.SP1:

  • Reintegrate the interceptors removal

    • Avoid the warns at startup

  • Allow to directly inject Nuxeo Runtime components and Services inside Seam beans

    • Remove the "Delegates"

Having our own version of Seam will also open the way for some other changes we may want to do:

  • Avoid the "Transaction Failed" message displayed by Seam when we rollback a transaction

  • Better manage conversation concurrency

  • Better manage context demarcation

Widgets Everywhere

Anahide is doing work on the WidgetDefinition to allow better configuration and code sharing. Evolutions on the WidgetType definition include:

  • Being able to define what type of field can be bound to the widget

  • Being able to define a default value

Operation Docs and WidgetDefinition

The current Operation definition can contain widgets that are used by Studio to know how to generate the form to let the user enter parameters.


@Param(name = "language", required = false, widget = Constants.W_OPTION, values = { NXQL.NXQL })
protected String lang = NXQL.NXQL;

For now these widgets are defined inside Automation itself, and have nothing to do with Nuxeo Layout/Widget system, this is a problem:

  • For understanding: the widget names and types are not the same

  • For code sharing inside Studio: Studio has to handle 2 types of widgets

This improvement as well as the addition of a description for the parameter will allow:

  • Studio UI improvements

  • Automation Doc website improvements

Widgets and Actions

In order to make the contribution of incremental layouts easier (less indirections Layout -> Category -> Action -> Widget), Anahide will allow to directly contribute a WidgetType inside the Action.

Action System and Context

The long awaited work to cleanup the way we build the Action Context has been done: NXP-10566


  • JEXL is out

    • Still used by runtime scripting: need to check if this is useful

  • Context initialization has been standardized

  • Seam context lookup is no longer a hack

Note: we still have nuxeo-platform-el, based on Unified EL, used in the audit and shiboleth source code.


Automation Evolutions

Params vs Context

With NXP-11096, Vlad started to allow passing parameters to Chains. Part of the implementation imply to allow fallback of empty parameters to Context entries with the same name.

We should go further:

  • Manage that at operation level

  • Review existing operation to be sure that all parameters are explicit

Feedback Messages

In a lot of cases, Automation chains need to generate user messages. Currently we have 2 options:

  • Return messages in the context with a known name

    • This will be displayed in JSF if the Automation Chain is called from the JSF UI.

  • Use a dedicated operation

    • Need to explicitly initialize Seam context first

And anyway:

  • Looking up the translation map is a pain

  • Passing parameters to the message is not always easy

We should provide a global solution for these use cases:

  • Provide a simple API inside Automation context

    • Add message with parameter

    • Translate a string

    • Get pending messages

  • Store the required info inside the context

  • Automatically flush the messages depending on the available context

    • Inside JSF if available

    • Inside the log

    • Inside Angular?

Vlad will check that and create the Jira issue.


The sample API (as you saw this week) has been improved. Next steps include:

Extend contextParameters

contextParameters are currently used in DocumentList serialization to be able to add URLs and links that can be used on the client side to save remote calls. This was introduced for OpenSocial use cases. With the Rest API, we would like to ask the server to add information inside the documents we fetch:

  • Get BreadCrumb info

  • Get Available actions

  • Get related documents

  • Get tags

This means that we should have a pluggable contextParameters management and be able to register on the server side some contextParameters providers.


Ideally, the rest API should provide a way to do bulk operation...

Android Connector

We have quickly defined the main tasks for the next weeks, based on:

  • What we know should be done!

  • Changes we have done in Automation on the Java side

  • Feedback from Julien's use cases

Cleanup Build

Align on a recent SDK using Google Maven repository: NXMOB-43

The work was started with Nicolas/Julien but needs to be finished.

Automation Client Alignment

The Android Automation Client is basically a fork of the original Automation client. As is, it contains features that are not in the Java client:

  • Caching

  • Off-line

  • Sync

  • Upload/Download manager

And of course, on the contrary, there are features of the new Automation Client that are not supported:

  • Jackson JSON

  • Business adapters

The task NXP-7804 exists for a long time to track this. Vlad will try to take a look with Nicolas, to see in more details what can be done without having to spend too much time on it.


The Android Automation client should support:

  • Token based authentication (the one created for Drive)

  • OAuth2

See NXMOB-44

Review Usage of Android SDK Concepts

The current Android Connector was designed on an old version of Android SDK. We should review the current architecture to be sure we leverage the possibilities of Android SDK:

  • Review how Nuxeo is exposed as a ContentProvider

  • See if we should package part of the code as an IntendService

  • Support for Fragments -...

Vlad will try to take a look with Nicolas.

Fix Activity LifeCycle Management

According to tests that have been done by Nicolas and Julien was have the following issues:

  • Init phase is done with a wrong settings (default one)

  • Shutdown can leak connections

  • Orientation switch can generate crash

See: NXMOB-46

Layout Manager

We want to improve the existing Android Layout manager:

  • Review widget binding system

  • Leverage new android widgets

  • See if we can leverage the layouts in the list views

See: NXMOB-47


The Automation Documentation is really becoming a mess. To improve things, we should:

  • Make Http API a first level entry in the documentation

  • Make an overview page that presents the 3 subset of http API

    • Historical REST API: get doc, download, export...

    • Automation JSON-RPC API

    • New Automation REST/HATEOAS bindings

  • Be sure we don't have too much resources dispersion between Studio and Dev docs

Automation Bindings

Dart by Nelson Silva

Nelson sent us some very good news that I'll share with you:

I've been updating my GitHub, Drone.io and pub packages for the Dart Nuxeo Automation client so you can now checkout:

I'll work some more on these as soon as I have an initial version of the sandbox working with polymer.dart.

For now I have just uploaded the initial version to https://github.com/nelsonsilva/nuxeo-dart-automation-sandbox

I'm just using the exec-maven-plugin to package the Dart application so it should be easy to integrate with your CI server.

I've also set up drone.io to package the sandbox https://drone.io/github.com/nelsonsilva/nuxeo-dart-automation-sandbox

Misc Platform Issues

CI and Build

Maven 3 Upgrade

Still needs to be addressed ASAP.

Marketplace Publishing from Jenkins

This is done and this seems to work!


Local Configuration/Flavors

Currently inside DAM, if people have defined flavors on some container, when using AssetBrowser view and navigating between the assets of different containers, it can trigger a flavor change (in Ajax) that will basically break UI.

We could investigate to fix this, but basically: we don't care about local flavors for AssetBrowser. This means the DAM view should not support placeful flavors.

Bulk Tagging

DAM bulk edit support tagging (using a Seam even to forward info). This code about bulk tagging should be added into DM. Since, Tagging is part of DM whereas Bulk Edit is part of CAP, we need a way to contribute the tagging widgets to the bulk edit layout. This is a good use case for incremental layouts!

For now Thomas is adding automatic versioning inside the BulkEdit. But we still have to figure out how we better manage automatic version creating in a consistent way.



Arnaud is working on NXP-11921 to switch Nuxeo from Metro WS to CXF:

  • This is good since CXF is better that Metro

  • This may help replacing the Jersey JAX-RS impl

For now, there are issues with Platform Sync: this may be a good opportunity to check this code and see if we can manage to find a way to test it automatically!