In my last post, I was writing that Perspectives are, for me, maybe the most interesting feature (or, at least, one of them) of Eclipse RCP when building applications for users. Jean-Marc Orliaguet read it and got a new idea : might this concept work for web applications ?

Since it's Jean-Marc and that he likes to have ideas but prefer put them at work, he started to work on this concept and see how it could fit in the Z3ECM project (next-generation ECM platform, buit on top of Zope 3).

What for ?

Imagine that when writing a new component, you also can easily define perspective. Let's take an example : a blog application. Well you can define a "Blog Perspective" that would be activated when accessing to a blog and that would arrange the portal to offer a "blog view" putting portlets in right places. WIth this and the whole CPSSkins machinery, it would be very easy to define interfaces that can adapt to user's activity.
The same approach would also work for webmail, calendar, collaborative work, personal portal dashboard, etc. The application would then only define portlets and perspectives (no more pages, view, whatever :-).
From the user point of view, it would really improve the usability and how it the portal can adapt itself to his need. The user would also be albe to define its own perspectives (like it's dashboard) and switch between them.

It would be new approach in the design of web applications, that would allow to think them as user-oriented applications and not as a chains of html pages.

Can I see it ?

Of course you can ! :-) Jean-Marc already implemented a prototype then made a post on his blog and a flash demo.

"Jean-Marc rocks !"(tm) :-)

Technorati Tags: cps, eclipse, ecm, nuxeo, rcp, rich client, zope, zope3

Introduction

Here, at Nuxeo, we are thinking for a long time at desktop applications for CPS. Why in this new full web, ajaxified, world ? :-) Well, I think that for many applications and features, a desktop application is still needed.

Here is some examples of features / requirements :

• Disconnected client to work in the train, in the plane, on the beach :-)
  • read, annotate, search in a document repository
  • use electronics forms when working outside the office
• Deep integration with legacy desktop applications (what about having OpenOffice running inside a dedicated client to improve cooperative work)
• Strong security : document signing, workflow action signing, etc.
• Advanced text edition : interactive diff / merge
• Advanced editors (photos, rich media, rich documents, etc.)
• Reduce server loads doing many computation on the client
• many, many more ideas :-)

We started to work, as some customers asked, on a desktop application. One point was clear: limit the burden of deployment!

Rich Client ?

We studied deeply Flash, Mozilla and Eclipse Rich Client Platform (RCP).

Flash was not standalone enough and too tied to graphics.

Mozilla seemed fine, but the current framework is too young (we were told by a proeminent Mozilla developer to wait for Mozilla 2.0 before investing on the technology) and not enough adapted to generic application, plus it needed us to write in C++ and had some fear about cross-platform compilation.

Eclipse RCP came then and we quickly discovered that it proposes an amazingly "sexy" framework, extensible, component-oriented and very well designed. But, besides those technical considerations, we mainly found that Eclipse RCP proposes a new approach and a new paradigm for desktop applications... very user-centric!

Eclipse RCP offers new concepts (at least, for me) for desktop applications, maybe inspired by webapp : actions, views, portlets, workspaces, perspectives, etc. Eclipse RCP comes, of course, also with a lot of interesting points for deployment and development: automatic on-line software update, lot of plug-ins, real cross-platform compatibility, SWT (a very fast graphic toolkit for Java), etc.

Perspectives ?

I think the most noticeable concept of Eclipse RCP to create applications for user is the concept of Perspective. A perspective is a view of your work space: portlet arrangement, toolbar, menu. It allows to offer several different ways to present the application, depending on the usage context. For example, you can have a perspective to edit a document, where the work space is document-centric, and a perspective to browse the document repository, where the work space is centered on navigation and searching. Moreover, users can define very easily new perspectives, dragging and dropping or adding portlets and then ask the application to save this perspective.

In short, it allows to adapt the application to user activity and working habits. It's the first time I am aware of a desktop framework offering this feature. Perspectives are designed to build user-centric / activity-centric applications and that is what users like, when you place them in the heart of the application usage paradigm. ;-)

Real-life projects

We now are working two projects based on CPS and Eclipse RCP. CPS is used as the document / content manager and Eclipse RCP as the framework to build a dedicated desktop application (let's call it Rich Client to CPS). The Rich Client connect offers UI and local features. CPS offers document management core. Best of both worlds ! ;-)

The first project is for AFP (French Press Agency) and aims at building the new news items management back-office. In this project, the Rich Client is the only CPS UI the user sees. The Rich Client is used by journalists to read internal news feeds, then write new documents, add / edit photos, manage the workflow and the output feed (rubrics, etc.). CPS, stores documents, manage permissions, serve the search, etc.

The second project is for the French Institute of Statutory Auditors (Compagnie Nationale des Commissaires aux Comptes, CNCC) and aims at building a system to manage documents and books authored and published by CNCC. CPS, here, is used to manage documents (authored with OpenOffice.org) and build books (collection of documents organized in a hierarchy / table of content). The Rich Client is the consultation interface of books : it synchronizes its local repository of books with the server, indexes it (in an RDF Database - Sesame  - for metadata and in Lucene for full-text) and offers to the user the reading/browsing/searching interface.

In both projects, the Rich Client proposes several perspectives, depending on user activity (users can also create their own perspectives), is auto-upgraded and communicates with CPS using HTTP and XML-RPC, RSS or ATOM.

First feedbacks from customers are very interesting and encouraging (users seem to really appreciate the interface). Feedback from our side is that the framework is amazing and allows very fast development thanks to the library of plugins and the quality of the software infrastructure offered. More details about those projects will be available soon (as soon as I find time to write on those :-)

The big picture for CPS Rich Client : the Personal Portal

Those projects, CNCC then AFP, are allowing us to create Eclipse plugins to communicate with CPS. We took then some time to plus those plugins together and offer a basic CPS client for offline work. It will be the base for next projects.

Our goal is to create a "pluggable" Rich Client that can be the Unified Rich Client for CPS so that users can work on CPS using this client or using a browser depending on their activity. We would like to be able to share as many features as we can between both client type: forms, portlets sources, actions, etc. That's where XForms, ATOM, XML Schema and stuff are taking place...

Imagine that, with this Rich Client framework for CPS, you would be able to quickly add a new feature and deploy it to all clients (for example a new application for users). Maybe even you can put this plugin to CPS and when clients connects to CPS plugins are installed, configured and available for the users. Users install the Rich Client (that can't do anything), then connect to the CPS instance and then get all components needed (an electronic form application, a collaborative work application, etc.).

We think this Rich Client as the personal portal of users, where they can do emails, calendaring, document sharing, specific corporate applications, all backed and stored into the corporate Intranet and also available with their browser. So fun ! :-)

Of course, all this code will be available as soon as we have some generic and useful codebase as Open Source software under the ZPL or EPL.

I will write more soon and often about those topics that can open a new world to document management, desktop applications and corporate Intranets.

To finish, I would like to thank IBM, the Eclipse Foundation and all Eclipse developers / contributors for creating and developing this amazing framework... Thanks to all ! :-)

Technorati Tags: zope, rich client, cps, eclipse, nuxeo, rcp

I am going further with AtomAPI support in CPSBlog. I have just added :

• DELETE support
• categories management as described in AtomSyndication

The AtomAPI support has been refactored to be more generic and split into 4 classes : AtomMixin, AtomAware, AtomAwareEntry and AtomAwareCollection. I still don't know if it's the best architecture for Atom support, and I know there is a lot of improvements to do, but it's better than yesterday ;-) This is the first step to a full Atom support in CPS. I think it should be possible to apply this Atom support to any document and folder so. And that would be the first step to a fully RESTful implementation of content syndication, cross-site publication and remote content management (let's talk now about native XMPP support, Atom extension, JEI-60, etc.). We will have to go further in this way very soon... The code is in CPSBlog trunk and should work with any AtomAPI client. I would be very delighted to get some reports with other clients.

Technorati Tags: atom, atomapi, cps, nuxeo, rest

I have implemented a partial AtomAPI support into CPSBlog, using specification and methods described by Blogger and Typepad AtomAPI.

This mainly allow blogging from desktop and mobile application.

Right now, CPSBlog AtomAPI implementation supports:

• adding entries
• editing entries
• retrieving and using categories (though some bugs seems to exists depending on the client)
• reading feed / entries

From a technical point of view, I've used the excellent lxml python component to parse incoming request and manage to also deal with SOAP enveloppe request (sent by some client, even if the server never says it accept it ! :-).

This blog will be posted using ecto on MacOS X (at least I hope it will work since it's the first post using AtomAPI on this site ;-). BTW, I was really disappointed to find out that there is very few AtomAPI clients (and almost none open source, but PyQLogger which seems to not work at the moment :-/).

How to get it working (taking this site as example):

• Protocol : Atom / AtomAPI
• Access / Entry Point : your blog URL/atomBlogServicesDiscovery (ex: http://blogs.nuxeo.com/sections/blogs/eric_barroca/atomBlogServicesDiscovery)
• Login / Pass : your usual login / password on the CPS site !

Then your client should get the required information and download the feed to allow you to post ! :-)

I would be pleased to get some feedback of using the API from other clients (Windows / Linux).

TODO:

• HTTP DELETE support to delete an entry
• pictures / files upload support (if I can find a client that supports it)
• test, test, test, test and more test !

Hope this help !

Technorati Tags: atom, atomapi, cps, nuxeo, rest