- FileSystemItem  // Represents any file on the fs
    | -- FileItem    // A File
         |-- DocumentBackedFileItem // Default adapter implementation for non-folderish document
    | -- FolderItem  // A Folder
         | -- AbstractVirtualFolderItem // Represents a folder on the client side, that is not backed by an actual document
             | -- DefaultTopLevelFolderItem // The default Nuxeo Drive folder, containing your synchronized documents.
         | -- DocumentBackedFolderItem // Default adapter for folderish document
              | -- DefaultSyncRootFolderItem // Adapter for the root synchronized doc. (put simply, the docs where you clicked on the sync button)
              | -- UserWorkspaceTopLevelFolderItem  // User workspace based implementation of the top level
              | -- UserWorkspaceSyncRootParentFolderItem // User workspace based implementation of the synchronization root parent

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:

  <extension target="org.nuxeo.drive.service.FileSystemItemAdapterService"
    point="topLevelFolderItemFactory">

    <topLevelFolderItemFactory
      class="org.nuxeo.drive.service.impl.DefaultTopLevelFolderItemFactory">
      <parameters>
        <parameter name="folderName">Nuxeo Drive</parameter>
      </parameters>
    </topLevelFolderItemFactory>

  </extension>

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 simply lists all the synchronization roots, which is to say all the document where you clicked on the Sync Drive icon. You can imagine different implementations like one that would display the content of your personal workspace along your synchronization roots. You could also have a hard-coded implementation that shows the same documents for every Nuxeo users. That’s really up to you :) . It doesn’t even have to be documents. You could have a folder called My Directories that would have a CSV file per directories declared in Nuxeo. (lots of coding involved but why not?)

Anyway, inside the default Nuxeo Drive folder you will see your synchronized roots and their children. This is managed by the org.nuxeo.drive.service.FileSystemItemAdapterService#fileSystemItemFactory extension point. Every one of these factories has an order attribute. They are resolved from the lowest to the highest. The first factory that returns an adapter is used. As you can see the lowest order is set on the defaultSyncRootFolderItemFactory. It will be returned if the adapted document has the DriveSynchronized facet. And the thing is, each time you click on the sync button, this facet is added to the document. As the child documents won’t have this facet, defaultSyncRootFolderItemFactory won’t match and the defaultFileSystemItemFactory will be used.

  <extension target="org.nuxeo.drive.service.FileSystemItemAdapterService"
    point="fileSystemItemFactory">

    <fileSystemItemFactory name="defaultSyncRootFolderItemFactory"
      order="10" facet="DriveSynchronized"
      class="org.nuxeo.drive.service.impl.DefaultSyncRootFolderItemFactory" />
    <fileSystemItemFactory name="defaultFileSystemItemFactory"
      order="50" class="org.nuxeo.drive.service.impl.DefaultFileSystemItemFactory">
      <parameters>
        <parameter name="versioningDelay">3600</parameter>
        <parameter name="versioningOption">MINOR</parameter>
      </parameters>
    </fileSystemItemFactory>

  </extension>

As you can see the defaultFileSystemItemFactory factory takes some parameters. They describe the default versioning behaviour. The adapter returned by the factory is DocumentBackedFileItem, which has a versionIfNeeded method called when the associated file is changing. This method first looks if the document needs to be versioned. This will occur if the current contributor is different from the last contributor or if the last modification was done more than 3600 seconds ago. As you have already guessed, 3600 is not arbitrary and comes from the versioningDelay parameter of the factory. If the doc needs to be versioned, the following code is executed:

            doc.putContextData(VersioningService.VERSIONING_OPTION,
                    factory.getVersioningOption());

We put the versioningOption parameter in the document context map. This information will be retrieved and used next time the document is saved. So by default, we do minor increments. Possible values are MINOR, MAJOR and NONE.

Customize the default configuration

Here’s an example of custom configuration of the default factories (no, we’re not going to write a complete new adapter or factory just yet). Let’s say I don’t want my Drive folder to be called Nuxeo Drive. I want it to be called ‘My Favorite Nuxeo Files’. And I also want to upgrade the major increment version number each time a document is modified using drive. This can be done using the following contributions.

<?xml version="1.0"?>
<component name="org.nuxeo.sample.drive.adapters" version="1.0">

  <!-- Make sure your contribution is registered after the default one -->
  <require>org.nuxeo.drive.adapters</require>

  <!-- Override the folderName parameter. No need to specify the class again as there can be only one topLevelFolderItemFactory. -->
  <extension target="org.nuxeo.drive.service.FileSystemItemAdapterService"
    point="topLevelFolderItemFactory">
    <topLevelFolderItemFactory>
      <parameters>
        <parameter name="folderName">My Favorite Nuxeo Files</parameter>
      </parameters>
    </topLevelFolderItemFactory>
  </extension>

  <!-- Override the versioningOption parameter. We need to keep the name of the contribution we want to override. The parameters will be merge with the existing one.-->
  <extension target="org.nuxeo.drive.service.FileSystemItemAdapterService"
    point="fileSystemItemFactory">
    <fileSystemItemFactory name="defaultFileSystemItemFactory">
      <parameters>
        <parameter name="versioningOption">MAJOR</parameter>
      </parameters>
    </fileSystemItemFactory>

  </extension>
</component>

Next week we’ll dig deeper into these factories and adapters.

The post Extend Nuxeo Drive Series #2 – Override existing adapter parameters appeared first on Nuxeo Blogs.

Extend Nuxeo Drive

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 override it, you need to declare your operation as usual, but don’t forget to use the exact same ID as the operation you want to override. Here I’m changing the date format to “dd-MM-yyyy hh-mm” and adding the user’s email address.

/*
 * (C) Copyright 2013 Nuxeo SA (http://nuxeo.com/) and contributors.
 *
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the GNU Lesser General Public License
 * (LGPL) version 2.1 which accompanies this distribution, and is available at
 * http://www.gnu.org/licenses/lgpl.html
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 * Lesser General Public License for more details.
 *
 * Contributors:
 *     ldoguin
 */

package org.nuxeo.sample;

import java.text.SimpleDateFormat;

/**
 * @author ldoguin
 */
// Use the same ID as the operation to override
@Operation(id = NuxeoDriveGenerateConflictedItemName.ID, category = Constants.CAT_SERVICES, label = "Nuxeo Drive: Generate Conflicted Item Name")
public class NuxeoDriveCustomGenerateConflictedItemName {

    @Context
    protected OperationContext ctx;

    @Param(name = "name")
    protected String name;

    @Param(name = "timezone", required = false)
    protected String timezone;

    @OperationMethod
    public Blob run() throws Exception {

        String extension = "";
        if (name.contains(".")) {
            // Split on the last occurrence of . using a negative lookahead
            // regexp.
            String[] parts = name.split("\\.(?=[^\\.]+$)");
            name = parts[0];
            extension = "." + parts[1];
        }
        NuxeoPrincipal principal = (NuxeoPrincipal) ctx.getPrincipal();
        String userName = principal.getName(); // fallback
        if (!StringUtils.isBlank(principal.getLastName())
                && !StringUtils.isBlank(principal.getFirstName())) {
            // build more user friendly name from user info
            userName = principal.getFirstName() + " " + principal.getLastName();
        }
        Calendar userDate;
        if (timezone != null) {
            userDate = Calendar.getInstance(TimeZone.getTimeZone(timezone));
        } else {
            userDate = Calendar.getInstance();
        }
        // I'll use a French date format
        SimpleDateFormat dateFormat = new SimpleDateFormat("dd-MM-yyyy hh-mm");
        dateFormat.setCalendar(userDate);
        String formatedDate = dateFormat.format(userDate.getTime());
        // and I'll add the user's email
        String contextSection = String.format(" (%s - %s - %s)", userName,
                principal.getEmail(), formatedDate);
        String conflictedName = name + contextSection + extension;
        return NuxeoDriveOperationHelper.asJSONBlob(conflictedName);
    }

}

Don’t forget the require tag and the replace)”true” attribute to make sure your operation override the default one:

<component name="org.nuxeo.sample.NuxeoDriveCustomGenerateConflictedItemName">

  <require>org.nuxeo.drive.operations.NuxeoDriveGetRootsOperation</require>

  <extension target="org.nuxeo.ecm.core.operation.OperationServiceComponent"
    point="operations" >
      <operation replace="true" class="org.nuxeo.sample.NuxeoDriveCustomGenerateConflictedItemName" />
   </extension>

</component>

That’s just a simple example, but you can do a lot more. Every call from Drive to the server are made through Content Automation. So that means you can override pretty much everything it does. All these operations are located in the nuxeo-drive-operations bundle. Most of them are using the FileSystemItemManager and NuxeoDriveManager services. I’ll write more about this in the next posts.

The post Extend Nuxeo Drive Series #1 – Override Operations appeared first on Nuxeo Blogs.

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 “Style class” property to “doItRed”…

…you save, and in the branding you create the doItRed style:

Then, you test your work⁽¹⁾.

. . . [here, I'm waiting while you are testing] . . .

You probably noticed something very unfortunate happened: It does not work as expected. The value we entered in the “Name” field is displayed in black. We want it red, right? So, how can we do this? How can we change the style of a widget?

Before explaining how you can customize this widget, I’d like to say you could have used one of the predefined classes provided by Nuxeo (and explained in the Nuxeo UI Style Guide.) For example, by using “warning” or “error”, our text would have been displayed in red. But here, we want it red-red, so we have an example of customization that can’t use a predefined class.

If you need the thing to be red now, immediately, can’t wait, emergency-emergency, then you may have the idea to use !important:

.doItRed {
    color:red !important;
}

And well, yes, it works. But the thing is: You don’t want to use it. Really. I believe !important has been added to the specification when the CSS team was spending time in Vegas with The Hangover folks. If you start using it, you’ll soon find yourself using it everywhere and at some point in a short future, nothing will work at all, your user interface will be broken. Instead of using it, it is better to understand why your style is not used. So, we remove this !important thing, save, update our project in the server and run it.

A web inspector is the perfect tool for the purpose of understanding what happened to our style.  So, at runtime, we display the inspector and select our widget. The right pane clearly shows that the class has been overridden (it is in strikethrough):

What happened here is that the default nuxeo theme, “galaxyDefaultCssNNN” (with NN being a number dynamically evaluated by the server) has been applied after our own class, hence the fact that our red color is not used.

What can we do to display our widget in red? We must (besides not using The Suffix That Must Not Be Named) use a CSS definition that will have a higher priority than the Galaxy one. Using the DOM ID of the widget would work, but it is complicated to get this ID, since it is generated at runtime (we don’t know this ID at the time we are adding the class in Studio). The best solution is to define our style by using the class hierarchy that is applied to our widget:

.classOfAncestor [...] .classOfParent .classOfElement {...}

So, we take look at the web inspector and find the classes:

It is good to be specific in the path and get the right ancestors. In our example, we want to apply the style only in the context of a task, so we walk the path up to “single_tasks_block”. The CSS we must define is:

.single_tasks_block .dataInput .fieldColumn .doItRed {
    color:red;
}

If you want to apply your red style in a wider area than a table, don’t hesitate to use the framework CSS classes: .nxHeader, .nxMainContainer, .nxFooter. These classes are called in all the pages of the platform.

There is one last thing to do actually: Our doItRed class becomes a place holder that we use for the “Style class” widget property. We can leave it empty. So, here is our CSS definition in the branding:

Save. Update⁽²⁾. Run. Enjoy.

We can now move a step further. Because at the beginning of the article, I was talking about displaying the field in red, but also as upper case. We want every character, every key hit by the user to be displayed as upper case.

How you implement this in Nuxeo Studio depends on what you need. Either you just want to display data entry in upper case, or you want the field itself, its content, to hold only upper case letters. Just displaying uppercase is quite easy — we add the appropriate text-transform style:

.single_tasks_block .dataInput .fieldColumn .doItRed {
    color:red;
    text-transform:uppercase;
}

That’s all. CSS handles the conversion at runtime. I’ll add that we should then rename our class, because giving useful names is useful⁽³⁾. If we do rename the class, we will not forget to change the “Style class” widget property in our task form.

Also notice that it is only about how the data is displayed: CSS does not change the actual content. In our example if the user enters “john” in the name workflow variable, it will be displayed as “JOHN”, but the variable itself still holds “john”.

If we want the transformation to be persistent, then we have to move to something different. Here is my suggestion: To stay with the CSS transformation for the display, and to add a “Transform to Uppercase” automation chain to the workflow. In our example, we added a basic “OK” button to the “First task” form. This button does nothing but move to “Second task”. We can now add an automation chain to the transition, which will be run when the user hits this “Ok” button. In the “Transitions” tab of the node properties dialog, click the “Create” button:

We name the chain “upperCaseName”. Our challenge is to set the name field to uppercase. It is a workflow variable. So we use the “Workflow context > Set context variable” operation chain. We can safely remove the first, default action (“Fetch > Context document”) that was created by Studio because we are not – in this example – using the document.

Here is what our chain looks like:

The “name” field is obvious: our workflow variable’s name is “name” (funny, isn’t it?).

Now what should we put in the “value” field of this chain to transform the characters to uppercase? You can use here a MVEL expression. Not everything is allowed in this context, but to make a long story short, basically, everything that is put between @{ and } is evaluated as a Java expression. Some expressions are very specific to Nuxeo, but you can also use a bit of Java here. And even more interesting for us, we can use its String class. And guess what? The String class has a toUpperCase() method whose function is quite clear in my opinion. This means that when you have a string, you just have to write…

myString.toUpperCase()

…to return a capitalized string. And a hard coded expression is also valid. I mean something like…

"nuxeo studio rocks".toUpperCase()

…returns “NUXEO STUDIO ROCKS”.

So basically, what we have to do now is to get the current value of the name workflow variable, and to transform it to upper case. Getting its value is done using the helper drop down menus of the expression dialog. We select “Workflow Variables” in first drop-down, then ["var"] in the second, and then we click “Insert”…

…this inserts the expression:

@{WorkflowVariables["var"]}

We replace “var” with “name”, since it is the name of our variable. The expression between the curly brackets is evaluated at runtime and returns a string: The characters the user entered. Because it is a string, we can call the toUpperCase() Java String method. We just need to be careful and to let the whole thing inside the curly brackets:

@{WorkflowVariables["name"].toUpperCase()}

We’re done with our automation chain, which contains actually one single operation:

We save, update and run. After starting a workflow on a document, here is my first task. I entered everything in lower case, “working well”. The CSS transformation displays it as we want:

Then, when I hit the “OK” button, the chain is run and “working well” is transformed using Java. So its value is now “WORKING WELL”:

Isn’t it wonderful that you can customize your application in such detail with Nuxeo Studio?

And don’t forget to add comments in your CSS to make it readable and easy to follow for you team^(5).

(1) Yes. Checking that what we do works as expected is part of our lives
(2) Update the project in the server. Something we sometimes forget. Then we wonder why our changes don’t work. Come on.
(3) Yes, that’s what I wrote: Useful is useful.
(4) If you are not very familiar with Java, it is not a problem at all. Finding the appropriate function requires a simple Internet search on keywords like “java upper case”. You’ll get an answer such as “use the toUpperCase method of the String class”
(5) Lise Kemen helped me a lot on this article. She is our CSS super specialist (see the Nuxeo UI Style Guide for example). She also she really insisted for this “comment your class” to be added. And when Lise really insists, well, you know, you just follow the orders.

The post Make It Red and Uppercase with Nuxeo Studio appeared first on Nuxeo Blogs.

How to add tagging capability during drag’n'drop

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 will be executed when dropping the files. The link will display an iFrame itself displaying the layout passed as query parameter (layout=dndTagsEdit). The schema query parameter (schema=dc) is used to specify which schema you need to update with the chosen layout. Take a look at the documentation for the other specificities of those actions.

<?xml version="1.0"?>
<component name="org.nuxeo.sample.dnd.actions.contrib">

  <require>org.nuxeo.ecm.platform.actions</require>

  <extension target="org.nuxeo.ecm.platform.actions.ActionService"
    point="actions">

    <action id="Chain.FileManager.ImportWithMetaDataAndTagsInSeam"
      link="${org.nuxeo.ecm.contextPath}/dndFormCollector.faces?schema=dc&#038;layout=dndTagsEdit"
      order="30" label="label.smart.import.with.mdTags"
      help="desc.smart.import.with.md.mdTags">
      <category>ContentView</category>
      <filter-id>create</filter-id>
    </action>

  </extension>

</component>

There are two things different from the classic import with metadata: the layout and the operation chain. The operation chain as an intermediate operation called Document.TagDocument. It’s responsible for the actual tagging of every document.

/*
 * (C) Copyright 2013 Nuxeo SA (http://nuxeo.com/) and contributors.
 *
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the GNU Lesser General Public License
 * (LGPL) version 2.1 which accompanies this distribution, and is available at
 * http://www.gnu.org/licenses/lgpl.html
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 * Lesser General Public License for more details.
 *
 * Contributors:
 *     ldoguin
 */

package org.nuxeo.sample.dnd;

import java.io.Serializable;
import java.util.List;

import org.jboss.seam.contexts.Contexts;
import org.nuxeo.ecm.automation.OperationContext;
import org.nuxeo.ecm.automation.core.Constants;
import org.nuxeo.ecm.automation.core.annotations.Context;
import org.nuxeo.ecm.automation.core.annotations.Operation;
import org.nuxeo.ecm.automation.core.annotations.OperationMethod;
import org.nuxeo.ecm.automation.core.collectors.DocumentModelCollector;
import org.nuxeo.ecm.core.api.CoreSession;
import org.nuxeo.ecm.core.api.DocumentModel;
import org.nuxeo.ecm.platform.tag.TagService;

/**
 * @author ldoguin
 */
@Operation(id = TagDocument.ID, category = Constants.CAT_DOCUMENT, requires = Constants.SEAM_CONTEXT, label = "TagDocument", description = "")
public class TagDocument {

    public static final String ID = "Document.TagDocument";

    @Context
    protected CoreSession session;

    @Context
    protected OperationContext ctx;

    @Context
    TagService tagService;

    @OperationMethod(collector = DocumentModelCollector.class)
    public DocumentModel run(DocumentModel doc) throws Exception {
        if (!isSeamContextAvailable()) {
            return doc;
        }
        List tags = getDndTagsFormAction().getDndTags();
        for (Serializable tag : tags) {
            tagService.tag(session, doc.getId(), (String) tag,
                    ctx.getPrincipal().getName());
        }
        return doc;
    }

    public static boolean isSeamContextAvailable() {
        return Contexts.isSessionContextActive();
    }

    public static DndTagsFormActionBean getDndTagsFormAction() {
        return (DndTagsFormActionBean) Contexts.getConversationContext().get(
                "dndTagsFormActions");
    }

}

As you can see, it retrieves the list of tags from a SEAM bean. It’s the backing bean of a new widget I have defined in my custom layout dndTagsEdit. This layout is almost the same as the original one, except it displays the tag widget. Take a look at the code and the documentation – it’s pretty easy to understand.

The post [Q&A Friday] How to add tagging capability during drag’n'drop appeared first on Nuxeo Blogs.

Atlassian HipChat

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):

/*
 * (C) Copyright ${year} Nuxeo SA (http://nuxeo.com/) and contributors.
 *
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the GNU Lesser General Public License
 * (LGPL) version 2.1 which accompanies this distribution, and is available at
 * http://www.gnu.org/licenses/lgpl.html
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 * Lesser General Public License for more details.
 *
 * Contributors:
 *     ldoguin
 */

package org.nuxeo.sample;

import java.io.IOException;
import java.io.UnsupportedEncodingException;
import java.util.Date;

import org.apache.commons.httpclient.HttpClient;
import org.apache.commons.httpclient.methods.PostMethod;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.nuxeo.ecm.core.api.ClientException;
import org.nuxeo.ecm.core.api.DocumentModel;
import org.nuxeo.ecm.core.event.Event;
import org.nuxeo.ecm.core.event.EventContext;
import org.nuxeo.ecm.core.event.EventListener;
import org.nuxeo.ecm.core.event.impl.DocumentEventContext;
import org.nuxeo.ecm.platform.url.DocumentViewImpl;
import org.nuxeo.ecm.platform.url.api.DocumentView;
import org.nuxeo.ecm.platform.url.api.DocumentViewCodecManager;
import org.nuxeo.runtime.api.Framework;

/**
 * @author ldoguin
 */
public class HipChatListener implements EventListener {

    public static Log log = LogFactory.getLog(HipChatListener.class);

    public static final String MESSAGE_TEMPLATE = "Document <a href=\"%s\">%s</a> has been modified by %s on the %s";

    public static final String BASE_URL = "https://api.hipchat.com/v1/rooms/message?format=json&auth_token=%s";

    public void handleEvent(Event event) throws ClientException {
        // First we make sure that the event is about a document
        EventContext ctx = event.getContext();
        if (!(ctx instanceof DocumentEventContext)) {
            return;
        }
        DocumentEventContext docCtx = (DocumentEventContext) ctx;
        DocumentModel doc = docCtx.getSourceDocument();
        // Once we have the document, we can start building the message we'll send to HipChat

        // First we build the document's URL
        DocumentView docView = new DocumentViewImpl(doc);
        DocumentViewCodecManager docLocator = Framework.getLocalService(DocumentViewCodecManager.class);
        String nuxeoUrl = Framework.getProperty("nuxeo.url");
        String docUrl = docLocator.getUrlFromDocumentView(docView, true,
                nuxeoUrl + "/");
        // Than the message body
        Date date = new Date(event.getTime());
        String chatMessage = String.format(MESSAGE_TEMPLATE, docUrl,
                doc.getTitle(), docCtx.getPrincipal().getName(),
                date.toString());
        log.debug(chatMessage);
        try {
            // now we can send it to HipChat
            sendMessage(chatMessage);
        } catch (UnsupportedEncodingException e) {
            throw new RuntimeException(e);
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }

    public void sendMessage(String message) throws IOException {
        // We retrieve every needed property from nuxeo.conf
        String roomId = Framework.getProperty("hipchat.roomId");
        String authToken = Framework.getProperty("hipchat.authToken");
        String userName = Framework.getProperty("hipchat.userName");
        String notify = Framework.getProperty("hipchat.notify");
        String color = Framework.getProperty("hipchat.color");

        // then we do the actual rest call to HipChat web API
        String url = String.format(BASE_URL, authToken);
        HttpClient client = new HttpClient();
        PostMethod post = new PostMethod(url);
        try {
            post.addParameter("from", userName);
            post.addParameter("room_id", roomId);
            post.addParameter("message", message);
            post.addParameter("color", color);
            post.addParameter("notify", notify);
            post.getParams().setContentCharset("UTF-8");
            client.executeMethod(post);
        } finally {
            post.releaseConnection();
        }
    }
}

What it does is simply relay the modify or create events to a room. This is the simplest integration possible, but there are many other cool use cases you can implement. You could have a dedicated room per Nuxeo group, you could integrate this with the notification module and send personal notifications, etc. Let us know what you think about this — are you using the same kind of tools to collaborate? Would like to see integrations between other collaboration tools and Nuxeo?

The post [Monday Dev Heaven] Nuxeo and Atlassian HipChat Integration appeared first on Nuxeo Blogs.

Access resource bundle label with MVEL

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:

package org.nuxeo.sample;

import java.util.Locale;

import org.nuxeo.common.utils.i18n.I18NUtils;

public class LocalizationFunctions {

    public static String localize(String bundleName, String localeStr, String key, String... params) {
        Locale locale = Locale.forLanguageTag(localeStr);
        return I18NUtils.getMessageString(bundleName, key, params, locale);
    }

}

Now that I have my function, I need to create an operation that will make this available within the automation context:

package org.nuxeo.sample;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.nuxeo.ecm.automation.OperationContext;
import org.nuxeo.ecm.automation.core.Constants;
import org.nuxeo.ecm.automation.core.annotations.Context;
import org.nuxeo.ecm.automation.core.annotations.Operation;
import org.nuxeo.ecm.automation.core.annotations.OperationMethod;

@Operation(id = AddLocalizationFunctions.ID, category = Constants.CAT_SCRIPTING, label = "AddLocalizationFunctions", description = "Add new function namespace to automation context.")
public class AddLocalizationFunctions {

    public static final String ID = "AddLocalizationFunctions";

    public static final String LOCALIZATION_FUNCTION_NAME = "LocFn";

    protected static final Log log = LogFactory.getLog(AddLocalizationFunctions.class);

    @Context
    protected OperationContext ctx;

    @OperationMethod
    public void run() {
        ctx.put(LOCALIZATION_FUNCTION_NAME, new LocalizationFunctions());
    }

}

This should do the trick. Now if I do an operation chain starting with this operation, I’ll be able to use this function:

    <chain id="test2">
      <operation id="AddLocalizationFunctions"/>
      <operation id="Seam.AddInfoMessage">
        <param type="string" name="message">expr:LocFn.localize("messages", "en", "label.permalink.description",{"param1", "param2"})</param>
      </operation>
    </chain>

Notice the use of an inline MVEL array to comply with String… params argument. Now you can go wild and add any functions you want. In the future we’ll try to make this extensible through an extension point.

The post [Q&A Friday] How to Access a Resource Bundle with MVEL in Content Automation appeared first on Nuxeo Blogs.

Nuxeo Drive

Drive 1.0.1 released

Drive 1.0.1 was release last week.

Next steps

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.

Oracle issue

There is a date formatting issue when doing Hibernate queries on Audit logs. => We should simply use Hibernate queryMaker to avoid that (AuditReader provides a method to allow parameters merge and will handle that!).

Technical tasks

Tomcat DS/Hibernate upgrade/Seam patch/H2 upgrade + MVCC branch

As already raised in previous tech reports, we still have several branches holding important infrastructure changes. We’re starting the merge of these branches.

• NXP-10926: H2 upgrade + H2 MVCC mode + use H2 in memory so speed up tests
• Tomcat Pool and ‘real’ XA mode + upgrade hibernate + patch Seam
• Improvements on test framework and error management (need to create ticket)
• Tomcat upgrade.

BIRT

A BIRT upgrade has been scheduled. The target is:

• upgrade to BIRT 4.2
• make an ODA connector for NXQL so that we can use NXQL from within BIRT designer.

PreSales sandbox

The PreSales team has started a sandbox where they code some extensions that can be useful for building demos and POCs. See nuxeo-presales-prototyping-toolkit.

Part of this work is also to fill the potential holes we can have in the API or in the Extension Point system. That’s why we did a quick review with Benjamin and a lot of the work should be directly merged inside the trunk:

• missing Operations
• Operation with missing parameters
• new Publisher extensions
• …

Automation

As already explained in previous reports, changes in Automation API are one of the cornerstone of the next release.

Automation improvements

• do some non-regression validation tests
• merge Olivier’s changes on JSON marshaling

Angular Layout/CRUD Automation/Automation

Damien has started working on:

• adding a REST CRUD API
• improving the JS client and make integration with AngularJS
• wrapping the Layout system

Layouts/Widgets/Studio/DAM

Widgets

Tabs widgets

We are almost ready to have a Widget that renders tabs defined by actions and allows Ajax Switching. This will be useful for DAM, but more globally, this would good for CAP too. So, the next steps include:

• finishing the implementation
• use by default in Nuxeo CAP tab system
• may be merging with changes on RESTDocumentLink for conversation management NXP-11331
• updating Selenium tests

Action types // Widget types

We are now very close to being able to use WidgetTypes to define Action types. The idea is basically to make action types more than a simple string attribute, but associate it with a set of property that can be defined by the user. Doing so would be good:

• for Studio, action configuration would be easier since we can have a form
• for documentation and showcase
• for Ajax behavior

Ajax Rerender and duplicated IDs

Depending on layout and widgets config there may some cases where RichFaces + Facelet infrastructure fails to correctly manage Ids. For now, this is a problem that:

• can be avoided via small workarounds in most cases
• can not be fixed in Nuxeo
• can not be easily fixed in JSF/Facelets

The JSF duplicate ID issue on ajax rerender has been identified, and fixed by using the nxu:repeat tag (revisited) and making it create new sub-components when it detects that the iteration list has changed. Otherwise existing components are reused and their ID is not reset, leading to potential duplicate IDs. See https://jira.nuxeo.com/browse/NXP-11434.

Anahide will try to submit the problem to RichFaces/JSF2 community to see if we have some feedback.

DAM

Box listing

The Box listing is used to manage the DAM thumbs view inside a ContentView. This works in DAM, but there is still some work to be done:

• integration inside CAP/DM to manage the ‘BigIcon view’
• standardize the DAM selection use case (clicking on the Thumb in DAM changes the currentDocument)
• Studio editor UI to be adapter to Box listing display
  • this is not strictly needed for now, but this would be really better.

Selection system

For ContentView the current selection model is built on the use of the DocumentListsManager. This system that is also used for Worklist and Clipboard becomes an issue for selection:

• when DAM and DM show the same ContentView but with different filters
• when there are several ContentView in the same page

If we allow to have several selection lists, this should impact the Copy/Past/Move actions available on ContentView.

Next steps

The next steps on DAM include:

• Tab Widget integration
• Html5 DnD integration for mass Import
  • start from existing code
  • add Canavas based preview if we have time
  • add support for async processing
• ‘Ajax Permlink’ (already discussed but not done)
• functional testing

Connect/Studio

Advanced Studio

Part of the ongoing work is about unlocking advanced feature so that people using studio don’t end up with a lot of XML Override in the XML extensions. This typically includes:

• Extended ContentView configuration
• Widgets configuration
• Selection configuration

Having all these new options:

• will unlock feature for advanced users
• may confuse basic users and lead them into problem
  • problems we will have to fix via support

This may be worth adding a disclaimer saying something like ‘use advanced settings only if you now what you are doing, support won’t be able to easily help you if you mess up something’.

The post [Nuxeo Tech Report] News from the Developer Front #6 appeared first on Nuxeo Blogs.

Some work on the Studio side is scheduled to enable some DAM-customizable features; however, a lot can already be done when you know what resources to use in Studio (document facets, form layouts, etc.).

To help with the learning curve, we have released an application template that you can import in your Studio project to test DAM customization.

A Studio application template is composed of projects and samples that you can use as a basis for your own project. To find out more, you can have a look at the Studio documentation on application templates.

What can you do with it?

The application template redeclares elements so that you can use, customize or override them with Studio. Here are a few things you can do.

Document model

Do you want to declare new document types that you will be able to see in DAM? No problem; the template just creates one to show you how it is done.

You can extend generic DAM types (picture or video). You can also choose DAM facets for your document type definition tabs, like “Picture” or “HasVideoPreview” for instance. You may also go to container types and allow the AssetLibrary so that you will be able to create your document directly at the root of the asset library.

It is possible to declare what document types can be created directly from the DAM interface using the right XML extension point. Look at the DAMEnableNewSampleCustomPic XML extension in your Studio project to see how to use it.

User interface (layout and actions)

Several layouts are now used in DAM. Thanks to the application template, you can now customize:

• the bulk edit form (damBulkEdit)
• the thumbnail layout (DAMThumbnailLayout) of assets
• the right panel (DAMRightPanelLayout): take a look at the XML extension if you want to see how to add form layouts.

And finally, new action categories are available so that you can put actions anywhere in the DAM interface:

• DAM View Actions
• DAM Current Selection List
• DAM Search Results Actions

How can you try it?

Are you ready to try it? It’s easy! In your Studio project (you can start a trial if you do not have a project already), go to Settings and versioning > Application Templates and import the template called Nuxeo DAM default, and you are good to go.

Make sure your Studio project is targeting the 5.7 dev version. If not, you can change it in Settings And Versioning > Project Settings.

Then get the latest build of the platform here: Static Snapshot. Install DM and DAM modules then deploy your Studio project in there and enjoy!

One last word: Please remember that you are trying a development version of Nuxeo DAM, so it’s a work in progress, and there may be impacts on this application template.

Related articles

• A Platform Approach to Digital Asset Management

The post Want to try customizing the new DAM with Studio? appeared first on Nuxeo Blogs.

We just released a beta version of Nuxeo Drive, a desktop synchronization tool for the Nuxeo content repository. We thought that a little story would be the best way of presenting this plugin, that you can yourself install it on your running Nuxeo 5.6 instance that is up to date with all hot fixes (through HF14). (This version is not compatible with a 5.7-SNAPSHOT Nuxeo server).

John Doe works as a sales rep in a pharmaceutical company. He is frequently at customer sites, presenting the product catalog. When he started with the company, they only had one drug on the market. The company has grown, the product line has grown, and the product documentation is frequently updated. Often, he doesn’t have the latest documents when on site. He is tempted to use one of many consumer cloud file sync services, such as Dropbox or Box, but knows that it is against policy and would violate basic security rules, putting his company’s intellectual property at risk.

John Doe has heard about Nuxeo Drive, the desktop file synchronization tool that simplifies the way you access documents stored in a Nuxeo content repository. John asks his sys admin to install the Nuxeo Marketplace package in the corporate Nuxeo Platform instance, a quick 2 min + server restart operation.

Easy client set up

John can easily see that the plugin is active because there is a new action button on every folder in Nuxeo. Then John goes to the Home tab, and notices a new sub tab on the left, called “Nuxeo Drive.” From that tab, he sees the “Download the Nuxeo Drive Client” section, and clicks on the Mac OS X link, which is next to the Windows package. Installation takes only a few seconds — he only needs to choose the location of the Nuxeo Drive folder. Then when starting Nuxeo Drive for the first time, John is prompted for connection information to his Nuxeo application. That’s a one-time task; after that, the URL persists and authentication is token-based.

Quick folder hierarchy synchronization

John now has a Nuxeo Drive folder on his desktop, but it is empty! He remembers seeing the synchronization icon in Nuxeo, and goes to the product presentations folder and clicks on the Drive sync icon. Immediately he can see under the local Nuxeo Drive folder that the synchronized node appears, as well as all the subfolders and files they contained. It was a big folder with multiple sub levels and thousands of documents, so it takes a little time, but John is impressed by the speed! And he can see on the taskbar a new Drive icon. Clicking on it gives him a status: 42 pending documents.

Offline access to documents

Unfortunately, John has to stop his experiment as he has a meeting in 30 minutes and he has not left the office yet. He closes his laptop and jumps into his car. There is no traffic and John arrives 10 minutes early for the meeting. This gives him time to review his slides. He finds them in the set of synchronized files in the Nuxeo Drive folder. Double clicking on the file launches PowerPoint as usual. He notices some spelling errors and fixes them, then saves the presentation. He also had to open and edit a second PowerPoint file caleld “animations.ppt,” where corporate drawings are stored.

Resume synchronization and conflict management

Back at the office, John is back online. The systray notification says 44 pending operations, actually the 42 pending downloads + the 2 uploads of files that were modified when he was offline. John is happily surprised at the robustness of the synchronization process. A few seconds after, the systray says “folder up to date.” Johns checks how the presentation was updated on the Nuxeo server. He browses the Nuxeo application and sees that a new minor version was created that includes his modifications. In the folder where the other file, the one with the animations is located, he now sees two files:  ”animations.ppt” and “animations.ppt (John Doe – 2013/04/08).ppt.” That’s because a conflict was detected at synchronization time, and Drive services let the users do the merge, keeping the two files safe.

Conflict resolution and new Live Edit action

Someone had updated the animations.ppt file while John was on the road. To resolve the conflict, Johns opens both files (either from the local Drive folder, or from Nuxeo using the new  ”Live Edit” action button, that now relies on Nuxeo Drive software) and uses a PowerPoint comparison/merge tool for resolving the conflict. He updates animations.ppt with his own modifications. Finally, he deletes animations.ppt (John Doe – 2013/04/01).ppt.

Managing all the synchronized root folders

John finds this new feature so useful that he starts clicking on plenty of folders he wants to synchronize. He noticed he can see the complete list of synchronized folders from the /Home/Nuxeo Drive screen and is even able to remove some of the synchronized nodes from there, so he doesn’t worry about synchronizing too many of them.

Documents and folders

John starts using Nuxeo Drive for more of his daily work. He discovers that removing files and folders locally will remove them on the server. Moving, renaming, deleting files on the server will do the same locally — all this is very simple and intuitive!

Token deletion and multiple devices

After an important presentation for a potential customer, John forgot his briefcase and laptop, probably in the lobby. As he doesn’t want someone else to have a way of always getting synced with the corporate Nuxeo document database, he uses the token revocation feature from the Nuxeo application, located in the Home/Nuxeo Drive tab. He also understands that on his new computer, he will just need to set up the client again, and it will already be configured. Nuxeo Drive can be used on multiple devices. It is a pragmatic tool for keeping your content repository available, whether you’re online or offline.

The post Nuxeo Drive – Desktop Synchronization appeared first on Nuxeo Blogs.

Meet Sylvain Chambon

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.

Listen to Sylvain’s interview (in French)

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 am specialized in Java-based software. There is a unit that does Java development, and another unit that I manage that does integration of complete solutions from pre-existing software like Nuxeo or Liferay, for instance.

What kind of projects do you usually work on from a functional perspective? When using Nuxeo, do you use document management, social collaboration, or digital asset management?

We are working on three projects at the moment. All of them are document management projects, with a strong emphasis on collaborative work. So, we use Nuxeo’s document management and social collaboration components. The main focus is good old document management, with an emphasis on business process automation, so that we are building a business document management application that’s more than just a simple repository. The strength of Nuxeo is that you can automate business processes and lifecycles and have something that is completely adapted to the organizational processes.

I’d like to find out more about your development processes with the Nuxeo Platform. What can you tell us about the fact that you can use Nuxeo Studio and/or Java and XML to configure and extend the platform?

So it’s always Studio AND Java, because Studio allows us to do 80% of what we want to achieve. For extending the Platform and more advanced development work, we need to write Java code.

Sometimes it’s much faster for me to write code in Java and it is easier to maintain the changes over time, because I have a source code management tool. I can see the history, the changes between two commits, etc. The difference between coding from scratch and using Nuxeo Studio is that you can’t see the differences between two commits in Studio, to find out exactly what has been modified. In general, Nuxeo’s development model (with extension points and bundles) may not be intuitive upon first glance, but as you dive a bit deeper, you understand the huge potential. And the fact that Studio generates a bundle, which itself contains only contributions to extension points, and that you can read this XML configuration, is incredibly powerful.

In a project we did recently, Nuxeo loaded 734 bundles — it was completely modular. We have a functional richness tied to this, and we can easily extend Nuxeo in one way or the other. I mean you can add functionalities or remove those you don’t want, or change them in a very clean manner. This is a really good point when you ask yourself how to maintain these applications over time. We are reassured because of the platform’s architecture.

We’re not going to ask ourselves existential questions about version upgrades, hot fix installations, you know, things like that. Globally it becomes routine, which is not the case for other products. Voila.

By Nicolas.F (Own work) GFDL or CC-BY-SA-3.0-2.5-2.0-1.0, via Wikimedia Commons

Open Wide is only open source. The open in Open Wide means open source. Contributing the code we write is part of the company’s DNA. It’s also a completely rational choice in that we don’t want to duplicate the version management and maintenance that a vendor does naturally, and better than we do.

And don’t forget that what you contribute is then maintained by Nuxeo :)

Exactly! That’s another way of saying it.

If you could have three wishes for the Nuxeo Platform, what would they be?

- I’d like to see an improvement in the rendering quality of the preview module. This comes from the choice to have an HTML-based preview instead of an image-based preview.

- I’d like to have the drag-and-drop upload form customizable with Studio.

- I’d like to have all of the elements from the social collaboration and digital asset management modules exposed in Studio’s application template, so we don’t have to redefine the picture type, for instance.

You live in Lyon, France. What is Lyon like?

Actually, I’m in Paris 80% of the time, and Lyon 20%, and I spend a lot of time in the TGV (the fast train in France). But Lyon is a beautiful city; I’ve lived there for six years. A good thing is that it’s more compact than Paris, so you can do everything on foot, very easily. Plus, you eat really well there!

What do you do in your free time, other than coding and contributing to Nuxeo?

Well, I code and I contribute to Nuxeo every weekend. This is all I do every weekend. [Laughs] No, seriously though… I read a lot. I have a three year old son and a full-time job. I also participate in micro-publishing projects for science fiction books by helping with the proofreading and reviewing process.

Can you give us a favorite book or author?

I just finished a science fiction book by Laurent Whale, called The Stars Don’t Care (Les Etoiles s’en Balancent) and it was “une pure merveille” – a joy to read.

By Otourly (Own work) GFDL or CC-BY-SA-3.0-2.5-2.0-1.0, via Wikimedia Commons

The post [Nuxeo Community] Meet Sylvain Chambon appeared first on Nuxeo Blogs.