Description

XWiki Integration with OpenOffice

Features from the user point of view:

The project is an extension for OpenOffice, which allows users to:

• view the wiki server structure (spaces,pages,attachments)
• create new wiki pages
• edit existing wiki pages
• open wiki pages in browser
• upload and download attachments
• edit attachments supported by OpenOffice

Architecture structure:

OpenOffice software architecture

OpenOffice is a complex and big software system. It has been designed as a client-server application system, which communicates via TCP/IP sockets. An installation of OOo implies installing the client and the server components on the same computer and the client would use the server component on the same system.

The component model of OOo is called "Universal Network Objects" (UNO), where each component is described in an interface description language (IDL) module. The OpenOffice.org is made from sets of UNO components, which communicate in order to provide the functionalities of the applications. This architecture allows different applications to share the same components.

Each UNO component (defined as an IDL type in a module) usually represents a specific "service", consisting of additional services, and possessing properties and interfaces (usual offering methods and properties to a specific aspect of the UNO component) to it. Properties allow the storing of information appertunant to services.

To create instances of service components one employs a "Service Manager", using either its method "createInstance()" or "createInstanceWithArguments()", supplying the fully qualified name of the UNO component. The returned object is called a "service object". Because service managers are used to create service objects, they are also called "factories".

The client-server communication between UNOs is performed using UNO remote protocol(this is similar with OMG from CORBA). At the transport layer it uses TCP/IP sockets.

Programming languages

The UNO components are implemented mostly by C++ programs that adhere to the type descriptions defined in the UNO IDL modules. After Sun bought StarOffice the UNO component technology was made available to the Java language by creating an appropriate proxy/adapter infrastructure into the runtime environment. The Java support for UNO allows the addressing of UNO components such as if they were native Java components. In addition the Java UNO infrastructure allows for creating and implementing UNO components fully in Java as well. OOo comes also with a specific programming language that is meant for scripting OOo components: OOo Basic. This language is modeled after Microsoft's Visual Basic.

How to develop an extension for OpenOffice?

OpenOffice.org enables third party tools creation through UNO bridges, allowing using many languages. The principle is to create UNO packages that can be listed in the OpenOffice.org Extensions repository.

In order to write an UNO, the programmer should specify the basic UNO components:

• Specification: definition in a common language of what the component should do. For UNO, this language is called UNO-IDL and is more or less similar to Corba IDL.
• Implementation: is the code that will realize what is described in the component specifications. This programming language can either be C++, Java, Python or others. This is the internal part of the component and will not be accessible from another component.

The extension file is an archive which has name that ends in .oxt (formerly .uno.pkg or .zip). It can contain UNO components, type libraries,resources (like pictures for example), configuration files, dialog or basic libraries, etc. UNO components will provide services, and Services implement interfaces. For the XOO, a UNO service for example will implement XJob or XAsyncJob, in order to handle the OpenOffice events like saving a document, open a new document etc.

From the user's point of view the extension will be integrated in the OpenOffice.org using Extension Manager (OpenOffice Writer ->Tools->Extension Manager->Add (browse to to XWiki.oxt file))

Tools:

• Netbeans plugin 
• Eclipse plugin (compatibility problems with OO 3.0 SDK - Cedric Bosdonnat is working on it http://cedric.bosdonnat.free.fr/wordpress/?page_id=11&lp_lang_view=en)

XOO Architecture

User interface:

Implementation details:

The main modules of the component should be:

• The communication with the sever (this functions are provided by XWikiXmlRpcClient class)
• The abstractization of the XWiki objects (spaces, pages, attachments etc) - these are provided by the Xwiki core API
• The core module (the back-end of the XOO). This should include: A ConversionManager which converts files between the two formats (for XWiki and for OpenOffice), the integration with a html cleaner, a StorageManager which manages the folders where the editing and the new temporal files will be saved, a StateManager who knows what files are opened for editing etc , a URL Manager that gives to every page and every attachment a complete name, and creates new names for the new pages.
• The graphical user interface. There are two approaches:
  • using OOo SDK API( http://wiki.services.openoffice.org/wiki/Extensions_best_practices )
  • integrate Java Swing (http://blogs.sun.com/alexismp/resource/developing-oo-module-netbeans.html)

The main functionalities of the application should be:

• A wizard for connecting to an XWiki server
  • Some dialog boxes where the user enters the server URL, the user and the password
  • Calls login() method from XWiki XmlRpcClient which invokes the login server's method
  • If the authentification is successfully done, calls getSpaces() method in order to get the spaces summaries from the server
  • The application should maintain a file with the authentification settings, in order to automatic connect to the specified server
• A navigation panel for browsing the documents inside the wiki
  • Displays the wiki structure as a tree
  • At onClick Event on a space - it is called getPages() method
  • At onClick Event on a page - it is called getAttachments() method
  • An option to view the entire structure (for every space, every document)
  • If there are some protected pages, they should be detected and deleted from the local wiki structure
  • Uses a timer which checks if the client is still connected to the server. If there is a connection it should be checked if there are some differences in the wiki structure
  • In the contextual menu, there should be an option (view the page in browser).This can be easy done from java.
• Downloading and uploading attachments
  • Upload:
    • Tests if the user can upload (is logged in, has salected a space etc)
    • Calls the method addAttachment() from XWikiRpcClient
  • Download:
    • DialogBox for the user to specify the folder there the document should be saved
    • Invokes the server function getAttachmentData()
    • Writes the received buffer in a file to local disc
• Editing attachments supported by OpenOffice
  • Verifies if the attachment is supported by openoffice
  • The user edits his document on the local disk and when he saves it (Save to XWiki button), the document is sent to the server
  • It can be added an option of saving the attachment in the entire XWiki every time when the user presses Ctrl+S for example
• Editing wiki documents in OpenOffice Writer
  • Verifies if the user can edit that page ( it is logged in, the page is not already opened etc)
  • Invokes the renderContent() method and the client receives the page in html
  • Converts the page from the its XWiki form to proper form for OpenOffice
  • Opens the page from OpenOffice Writter (OpenOffice SDK has a method loadComponentFromURL )
• Creating new documents
  • The user has to mention the space for the new page, the name and the title
  • A new document is opened in OpenOffice Writer (an URLManager should make sure that the document will receive a unique name
  • When the user saves the page,the page is converted in a format for XWiki and then invokes the server' s function storePage()