Email:       Twitter: @dbrucegrant

Nuxeo Studio - Revisited

I recently made the time to revisit Nuxeo Studio to assess it as a prototyping platform. I say revisit, because early versions were less than useful and I made the decision to steer clear until the environment matured somewhat.

I was pleasantly surprised this time around with what I found. The interface, the breadth of functionality, the help system, and the volume of examples all have improved substantially.

Using Studio to prototype schemas, documents and user interface definitions (in all modes) greatly reduces the volume of XML coding and eliminates errors associated with hand-coding XML. Beyond the basics I used Studio to:

  • Create an advanced search that included a custom document type field
  • Added custom content views
  • Created several virtual navigations on custom metadata
  • Developed some automation chains to pre-populate data into newly created Document models
  • Add several custom vocabularies
  • and more

All of these actions generate the necessary underlying XML and other components necessary to customize your instance of Nuxeo. This allowed me to developed a base look and feel and functionality much more quickly than in the past.

Given that my intent to use Studio as a prototyping mechanism (because there are many requirements that cannot be met using Studio), I found two significant issues with Studio:

1. The XML output produced is in a single contribution file - would be MUCH BETTER if this could be split into functional files for those of us taking the output of Studio and importing into an Eclipse project! Far easier to manage the XML in multiple files than in a single monolithic file. In my opinion this should at least be an output option.

2. The XML output produced - most notably the WebLayout contributions become very large in very short order, due mostly to the fact that there is no mechansim as yet to identify what is a shared widget (that is a widget used in multiple layouts) versus a widget that is unique to a given layout. For example, if a custom drop-down widget is used in 10 layouts then there is 10 instances of the widget definition. This can, of course, be rationalized once imported into Eclipse, but it is time-consuming and fraught with the dangers that manual edits bring in substantive XML files.

Even with these limitations I believe that Studio is worth your time. And I have no doubts that the product will only get better over the coming 12 months.

Trackback URL:

Add Comment

Hi Bruce,
Thank you for your feedback. We are glad you noticed improvements over the last year. Indeed, Studio roadmap in the coming months is exciting with "tab designer" to make new tabs, workflow designer, ...
I want to take time explaining here some reasons of the limitation you identified.

First, using Studio as a bootstraper for your Eclipse project is not the target. We aim at making Studio complete enough so that the user never has to "fall back" on Eclipse, needing to commit what Studio genrated and modify it. The main reason for this is that one of the biggest value of Studio, beside above-mentioned time-saving, is the fact that everything done in Studio can be re-generated for a newer version of Nuxeo, facilitating greatly the maintenance of your customizations. Studio guarantees the compliance of your customizations over the time. Which is not the case if you start "forking" the code.

I'll let a second comment later this week for talking about layout widgets. We have some ideas to improve the factorization of definitions while not endengering the ease of use.

Posted on 3/20/12 8:23 PM.

Post Reply Top
(Alain, Nuxeo)

Posted on 3/20/12 8:23 PM in reply to .

Post Reply Top

Recent Entries Recent Entries

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