App Dashboard

You are probably curious about the XOO status. Well I will begin to present the functionalities with screenshots, after that the known issues and future development.

NOTE : I apologize to the Windows Users. Unfortunately the extension is not very user friendly because the navigation panel loses every time the focus and the user has to press the navigation panel button again or to minimize the window in order to work easy. This issue appears only for Windows.I've mention at the known issues section details about the Navigation Panel problem. Of course the functionalities work for Windows too, but this issue makes the experience not very pleasant.

XOO functionalities

XOO installation

XOO can be installed in OpenOffice using Extension Manager

XOO toolbar and menu

After you install XOO, you will notice a new Toolbar and a new Menu Option (XWiki). The user takes advantage of the XOO functionalities through this elements ( Toolbar buttons and Submenu options). When the mouse is over one of the toolbar buttons, there is a help text that specifies the button functionality.

Login

If the user has customized the XE installation, he/she has to specify the wiki relative path to the server and the XML-RPC relative path. The default values are "/xwiki" and "/xmlrpc"

Navigational panel

The user can visualize the structure of the XWiki server, using the navigational panel. With this one there are some problems,but I will talk about them at the known issue section.

Edit a page

The user can edit with OpenOffice an existing page selecting the page in the navigation panel and using "Edit page button"

The XWiki Syntax is transformed in XHTML. If the page contains images that are attached to the current page or to another page, the images are downloaded locally and the user sees them when he edits the page.

When the user edits a page, can include also other images from the local machine.

These images will become attachments for the current page, if the page will be publish to the server.

Publish a page

After the user edits an existing page, he can publish it using the "Publish button".

Any other HTML created or opened with OpenOffice can be published. In this case, the user is requested to specify the name of the page and the space. where the current page will be published.

If the page contains pictures, these one become attachment for the page. Currently this operation is not optimal. All the pictures are sent to the server not only the modified ones.

View a page from the server using the default browser

Add a new page to the XWiki Server

Add a new space to the XWiki Server

Attach the current document to an XWiki page

The user can attached an opened OO Writer file, to an existing XWiki page, after he/she selects in the navigation panel the page that will be the parent.

Download attachments

The attachments can be downloaded to the local machine.

The user has to specify the location where the attachment will be downloaded.

Known Issues

My first big issue was the Navigational Panel.The ideal one should be a docking window for each opened document. Currently , it is only one instance in the whole extension which is of course not the happiest approach. I read the developers guide from OpenOffice, I tried different "solutions" but none worked. On the OO developers list after 3 weeks of mailing I've received the answer:

"Hi Christina,

Sorry for the late answer but I have tried to look for a solution. Unfortunately I wasn't able to find anything what can help you here. The object you get via the DialogProvider service just implements XDialog and XTopWindow neither implements anything that you need. I fear that your workaround is currently the best available solution. Please write a request for enhancement and the owner to cd@openoffice.org. I hope that we can extend the implementation to support your use case."

Fortunately, today I've received a mail form another developer that gave to me some hints to implement it. Not as docking window, as modal -less (so it is now) but handling the events. We have to decide if we change the design or I should try (it is some work to do) to implement this way. If you want to read the email thread I was talking about you can find it here: http://www.nabble.com/DockingWindows-Java-ts24754063.html

There are more issues and I registered them in Jira. http://jira.xwiki.org/jira/browse/XSANDBOX/component/10799 Feel free to add more.

OpenOffice API development

I'm sorry to write that, but the API from OpenOffice was much more tricky as I've expected. It is not well documented, many things are missing (docking windows, complete open folder control, an easy way to get the extension path etc) . For example, I didn't expected to add an icon at a button to be a big deal. Well I was surprised that OO doesn't accept relative path, only absolute URL, so I had to get the extension path. The solution suggested by OpenOffice.org was to write a configuration file (to be recognized this file should have a defined schema too), in that file to set a property with the value "%origin%" which is a macro that contains the current path. After that, from java code, I had to read this file and call the MacroExpander to get the real value. It's incredible that I waste a lot of time with that small window for the navigation and the problem still persists :-|

Future development

The next things to do are to find solve the navigation panel problem, add support for all the documents with macros, add some progress bars and find a way to minimize the time to get the XWiki server structure , solve the openoffice style problems and so on.

I'm looking forward for your feedback on my project!

Executable

You can find an executable with my extension attached here

If you can't download it, you can find a link here

This one was tricky!

The objective was to make the xeclipse handle a large wiki, wrt the navigator, of the range of 1000+ pages in a space. Previously, while expanding the node of space, the UI was blocked and went into an unresponsive stage, and came back/became responsive after all the tree was loaded.

Now, the current implementation does this.

• Creates a Job that asynchronously gets/updates the tree every 200msec.
• Creates a Job that fetches the nodes in batches [of 20] and adds to the Tree
• Creates a pending node at the end of the tree, which is removed once when job 2 completes.

Now, the tree loading is done as a Job, and hence does not block the UI. The scrollbar is not perfect always, because the pages are added over time.

Other actions, opening pages, expanding other nodes, can be done, while the lazy retrieval is taking place.

1. Drag and move Attachment -> Drop on some other Page (Of same space/ other space) If the space is not expanded previously, then should expand and show pages. Should Deny Drop on Space/attachment/embedded objects. Name is retained. rpc.moveAttachment is used. No need to expand pages, when hovered over with attachment. The Spaces/pages should be refreshed Accordingly, new notification instance (MOVE_ATTACHMENT)
2. Drag and move Page -> Drop it on another Space. Name is retained. rpc.movePage is used. Deny Drop on other pages/attachments/objects. No Need to expand spaces/pages when hovered over. The spaces/pages should be refreshed accordingly, new notification instance (MOVE_PAGE). Drag under effects of Feeback_insert_after.. etc is not required.
3. No Drag/Drop for spaces/objects. (Drop_NONE)
4. Copy of Attachments. If Drop_copy specified, by key trigger. Almost as same as 1st point above, only use rpc.copyAttachment. If copy to same page, then newfileName should be "Copy of "+oldfileName
5. Copy of Page. Same as second point. rpc.copyPage used. If copy to same Space, then the newPageId should be (space).Copyof(oldpageID). There is some XMLRPC Bug with the implementation.

1. DND of Pages between Spaces (That should automatically dnd their corresponding attachments also)
2. DND of Attachment between pages.
3. Automatic expansion of (+) spaces/attachment on drag action.
4. Preventing illegal dnd's
5. Drag and Drop Between with cnf and Editor (will have to see if possible)

1. Creation of renameAttachment xmlrpc function, and a better renamePage() function. -DONE
2. Creation of a generic XWikiModelObjectTransfer for handling TransferTypes. - Not Required for CNF
3. Creation of DND sources and targets DONE
4. Creation of feedbacks, UI features, intuitive elements. DONE

In this post I will talk about how I implemented the Bidirectional Converter for my extension.

I've used the existing code from the XWiki platform rendering module. In order to be able to do this, I've created a new instance of EmbeddableComponentManager . This object is initialized just once in the whole extension, in the XWikiExtension class.

xwiki 2.0 syntax -> xhtml

• I've used a Parser for XWiki 2.0 syntax. The result is the a XDOM structure
• I've applied transformation on the XDom object, for the macros
• I've used a Renderer for XHTML.

• I've used a Parser for xhtml syntax. The result is the a XDOM structure
• I've used a Renderer for XWiki 2.0 syntax.

It's been a while since my last post, and I apologize for that. Consequently, this post will be longer than the usual ones, and I will talk about what I have done recently.

First of all, not it is easier to build the project (run just mvn install). For more details, please read the README file associated with the project. I've also attached at this post a version of XOO. In order to log in you should provide the complete URL of the server (for example if you want to connect to the local XWiki server you can try url: http://localhost/xwiki/xmlrpc~~ , username ~~Admin, password admin. After you are logged in, you can see the structure of the XWiki server choosing Menu->XWiki->Navigation Panel. Right click on a page name and OpenOffice will open the html page (the conversion in xhtml isn't ready yet, and that's why you will see the syntax of the page , not interpreted).

So let's talk about the components:

• The navigational panel . Here I had a problem. I wanted something similar with the custom control from XWord, but I didn't manage to find a solution. So for now, I thought to have a dialog with the tree structure. By default, the OpenOffice dialogs are modal. That means, the focus is on the dialog, and the user cannot do something else until he closes the dialog. I needed of course a non-modal dialog. Unfortunately, there was very few documentation about how to do it, so I wasted some time. The solution I've implemented is this one: create a new window with the desktop as parent and display the dialog provided by the dialogProvider Service in this window. In this case, the user can also edit a text and having the navigational panel on the screen. I will paste here some code, maybe it is useful for somebody who has the same problem.

obj = xMCF.createInstanceWithContext("com.sun.star.awt.DialogProvider2", m_xContext); XDialogProvider2 xDialogProvider = (XDialogProvider2) UnoRuntime.queryInterface(XDialogProvider2.class, obj); XDialog xDialog = xDialogProvider.createDialogWithHandler(DialogURL, this);

XControl dialogControl = (XControl) UnoRuntime.queryInterface(XControl.class, xDialog); XControlModel xBasicDialogModel = dialogControl.getModel();

Object dialog = xMCF.createInstanceWithContext("com.sun.star.awt.UnoControlDialog", m_xContext); XControl xControl = (XControl) UnoRuntime.queryInterface(XControl.class, dialog); xControl.setModel(xBasicDialogModel);

XToolkit xToolkit = (XToolkit) UnoRuntime.queryInterface(XToolkit.class, xMCF.createInstanceWithContext( "com.sun.star.awt.Toolkit", m_xContext));

WindowDescriptor aDescriptor = new WindowDescriptor(); aDescriptor.Type = WindowClass.TOP; aDescriptor.WindowServiceName = ""; aDescriptor.ParentIndex = -1; aDescriptor.Parent = xToolkit.getDesktopWindow();

aDescriptor.WindowAttributes = WindowAttribute.BORDER | WindowAttribute.MOVEABLE | WindowAttribute.SIZEABLE | WindowAttribute.CLOSEABLE;

XWindowPeer xPeer = xToolkit.createWindow(aDescriptor);

XWindow xWindow = (XWindow) UnoRuntime.queryInterface(XWindow.class, xPeer); xWindow.setVisible(false); xControl.createPeer(xToolkit, xPeer);

m_xDialog = (XDialog) UnoRuntime.queryInterface(XDialog.class, dialog); m_xControlContainer = (XControlContainer) UnoRuntime.queryInterface(XControlContainer.class, m_xDialog);

The navigational panel is not in the right place,for now. I will do more research about another way to implement this control. If the dialog remains the only choice then some coordinates should be calculated.

• File storage. In order to edit, create a new page and publish a new one, I create some temporal files that stores the information. So for every page I create a folder in the default java temp folder. This folder will contain the page itself in html and the objects associated with the page (images for example). In this scope, I've created a class that handles all the work with temporal files.

• Opening a html file from OpenOffice. OpenOffice works only with URLs, so I had to convert the file's path in a url using XFileIdentifierConverter interface

• Converter XWiki syntax - xhtml. I'm working on this now. I tried to implement it (http://svn.xwiki.org/svnroot/xwiki/sandbox/gsoc/xoo/src/main/java/org/xwiki/xoo/xwikilib/converter/internal/DefaultBidirectionalConverter.java), but I have an exception at the rendering step. If you have any idea what I am doing wrong, please let me know.

• Download and install maven google web toolkit archetype. Download maven-googlewebtoolkit2-archetype-1.0.4.jar file from this link. GWT-Maven Archetype
• Install the downloaded maven archetype

mvn install:install-file \
   -DgroupId=com.totsp.gwt \
   -DartifactId=maven-googlewebtoolkit2-archetype \
   -Dversion=1.0.4 \
   -Dpackaging=jar 
   -Dfile=path/to/downloaded/jar/file/maven-googlewebtoolkit2-archetype-1.0.4.jar

• Now you can create the maven GWT project with the following command running in terminal

mvn archetype:create \
   -DarchetypeGroupId=com.totsp.gwt \
   -DarchetypeArtifactId=maven-googlewebtoolkit2-archetype \
   -DarchetypeVersion=1.0.4 \
   -DgroupId=myGroupId \
   -DartifactId=myArtifactId

• After all this, you can run your GWT project in hosted mode and take all GWT advantages using following command

mvn gwt-maven:gwt

• Or you can build a WAR file using this.

mvn clean gwt-maven install

• Title: XWiki Widget and Firefox extension
• Objective: The objective of this project is to make relevant information from a wiki accessible in a widget.
• Student: Alexandru Cismaru
• Contact: alex.cismaru@gmail.com

 Project Description:

The world has seen an explosion in the use of widgets over the past year or so, and it's time for XWiki to have it's own web and desktop widgets.

User Experience The most important thing in this project is, in my opinion, the user experience. If the users don't experience quality throughout the widget, they may conclude there is a lack of quality everywhere. This means we need to pay attention to the quality of icons, images, text, background, and interaction. Each of these elements is equally important (maybe only the data is more important).

Fresh Data. The widget should display only information that changes often, information that is static for more than a day makes a widget dull. A user looks to a widget to see interesting things that are active.

Choosing the information relevant to individual users. I think a tabbed interface is the best choice for the user interface, with three tabs: General, Watchlist and Search. The General tab will display general information of a wiki: the most recent modifications, the spaces and the tags. Widgets are all about user choice and preference. That's why I propose to have a tab with the information from the Watchlist and offering the possibility to add his own rss feeds. I also think a search tab that will display a list of results is useful.

Interface design. We need to keep the widget simple and aesthetically pleasing, to show only relevant information. I want to use icons, images, and signs as much as possible; they give visual clues of the functionality. The design of the widget should not be too obtrusive. The use of buttons and user controls should be avoided at all costs (that's why I preferred using links for refresh and logout actions instead of buttons) .

Design Patterns. Developing a widget is like developing any other  software product, so we must have some design patterns to follow in order to make development easier. My approach is to concentrate on: maintainability, customizability and extensibility. By making a good separation of modules, and writing reusable code helps to maintain the widget and makes it easier to add new features. Because we want to release a XWiki widget on as many platforms as possible, I think it's important to make the widget easy to be customized for a specific platform. Another desired trait of the widget is extensibility, this way the widget can be used to extend existing functionalities.

Finally, I've implemented a first feature for the XOO project : the wizard for connecting to a XWiki server

In order to achieve this goal, I've created the following classes

• XWikiDialog.java - this class is the base class for all the Dialogs that I need in the application. It contains methods like create a new Dialog , get the set of the properties of a control from the dialog, dispose the dialog. It was necessary to create this kind of class because in the OpenOffice API is not simple to create a dialog. (I have to use the DialogProvider service which gives the dialog created with the basic editor using the URL parameter).

• SettingsDialog.java - this class extends the XWikiDialog and represents the Dialog which appears when the user wants to change the connection settings. For now, it has only 3 fields for the server url, username and password

• Settings.java - this class contains all the settings made by the user. For now it has only 3 attributes (server url, username and password). It can be more generic if I use a dictionary structure instead of all those attributes

• Utils.java - this class displays useful messages for the user (like the error messagebox when there cannot be established a connection with the XWiki server).

• XWikiAddIn.java - a singleton which contains the XWiki stucture, the XMLRPCClient and the settings.

• Debug.java - a singleton used for displaying messages for debugging

• IConstants.java - an interfaces with all the constants from the project. I find this interface  useful especially for the localization.

If you want to build and install the XOO project, you have to follow this steps:

1. Download and install OpenOffice.org 3. from http://www.openoffice.org/
2. Download and install OpenOffice SDK 3. from http://download.openoffice.org/3.1.0/sdk.html . A useful link is also : http://wiki.services.openoffice.org/wiki/SDKInstallation. If you want to be sure that the installation worked, try to build one of the examples from the SDK folder. In order to be able to run an example you have to set the environment variables for the SDK. (Run one of the setsdkenv script)
3. Download the CVS project http://api.openoffice.org/source/browse/api/maven2integration/ and run mvn install in order to install the maven open office plugin in the local repository
4. Enter in the root folder of the XOO project and run
   mvn assembly:assembly -Dooo=/path/to/OpenOffice.org_installation -Dooosdk=/path/to/OOSDK
   ex: mvn assembly:assembly -Dooo=/home/kristina/opt/openoffice.org3 -Dooosdk=/opt/openoffice.org/basis3.0/sdk
5. In the target folder there is an archive xoo-1.0-bin.zip. This is the extension. In order to install it run:
   $ unopkg add --shared xoo-1.0-bin.zip
   Another method to install the extension is:
   OppenOffice.org Writer -> Tools -> Extension Manager -> Add -> Browse to the path of the zip file xoo-1.0-bin.zip
   Restart the Writer.; A new menu XWiki should be enabled.

Soon will be added also tests. If tou want to run only the tests: mvn test