Release Notes for XWiki Enterprise 1.9 Milestone 2
Release Notes for XWiki Enterprise 1.9 Milestone 2
Second milestone of the XWiki Enterprise 1.9 version (Roadmap).
New and Noteworthy
At a glance (see below for details):
- Lots of improvements and new features in the new WYSIWYG editor
- Lots of UI improvements
- Lots of improvements and bugfixes in the rendering engine and the syntax converter
- A new LiveTable widget
- Improvements for the PDF export
- Started cleanup and refactoring of the JavaScript APIs
- Switched to UTF-8 as the default encoding
- Upgraded to Velocity 1.6.2
- New Dutch translation, improved French, German, Spanish, Romanian, Russian translation.
- Mailsender improvements
1 UI improvements
1.9.M2 contains several improvements enhancing the usability and productivity on the wiki. These features are under development, so they might still have buggy or limited behaviors. These quirks will be fixed in the next releases.
Many thanks to Marta Gîrdea, who supervised the development of most of these improvements.
Quick Jump to any Page navigation
It is now possible to jump from any page to any other page, using a modal dialog aided by a suggest-powered search. To start, just press Ctrl+G or Meta+G (the meta key is the one between Alt and Ctrl, usually with a Windows logo on it, or the one with the Apple logo on Macs), or click on the text from the Quick Links panel.
The modal dialog appears in the upper part of the page, and provides an input where the users must introduce the full name of the document they wish to view.
Start typing, and a suggest box will offer documents matching your search criterion (at most 10 documents are displayed for the moment). You can use this suggest as any other suggest box in XWiki: Up and Down move the selection, while Enter puts the currently selected value in the input.
To go to the selected page, just press Enter once more (this will open the document in view mode), or use one of the two buttons on the dialog, or press Ctrl+V or Meta+V to view, and Ctrl+E or Meta+E to edit the target document. Esc simply closes the dialog without changing the current page.
Known issues:
- Some of the shortcuts are not available on all systems and browsers (for example Chrome), and they inhibit some of the browser's native shortcuts (for example Ctrl+G on Firefox normally searches for the next occurrence of the searched term, but F3 does the same thing).
- The suggest box searches only on the document name. The next release will bring support for quick search by the document's title.
- The suggest box displays at most 10 documents. It should be possible to fetch more results when pressing the Down arrow after the last item.
- The edit button does not open form-based documents in the inline editing mode, but in the configured editor (wiki or WYSIWYG). This will probably be fixed in the next release.
- Typing just the name of a document, without the space, does not open a document in the current space, but in the view space. This will be fixed in the next release.
- It is not possible to enter more than one search term, separated by spaces, since the suggest searches for an exact match of the input string. This will be fixed once the overall REST-based search will be improved.
Faster Save and Continue using AJAX
Save and Continue doesn't refresh the page anymore, but makes an AJAX request to save the document. When pressing the Save & Continue button, or the Alt+Shift+S shortcut, a message appears at the bottom of the screen, indicating that the document is being saved.
Since this action is performed using AJAX, much less processing is required on the server, and much less data is transfered between the server and the client. Before you even notice it, the message quickly transforms into a Saved notification, then fades away.
If an error occurs, you will be notified of the problem by a similar notification message:
As a related minor improvement, the Cancel button also behaves faster. Until now, it used to submit the entire form back to the server, although the data was discarded. Now, a simple request without any data is made, thus reducing the network traffic and the total response time.
Improved Full Screen editing
XWiki had a full screen editing mode since 2007, when it was implemented thanks to a Google Summer of Code student. But it had several limitations that made it less useful than it should have been:
- It had a particular look that didn't integrate well with the current skin
- It didn't have the action buttons allowing to save or preview the document
- It only worked with the main content editor, and only for wiki editing and the old WYSIWYG editor
- It had several minor bugs on different browsers
This feature was completely rewritten, addressing all of these issues. To start editing in full screen, press the button available in the toolbars of the wiki editor and the WYSIWYG editors:
The editor will then take the entire available space, preserving only the toolbar and the action buttons. You can now save the document right from the full screen interface, and even take advantage of the new AJAX Save and Continue to quickly save and remain in full screen. To return to the normal view mode, push one of the two available buttons (one in the toolbar, and one next to the action buttons).
You can also edit in full screen any textarea in inline mode and in the object editor:
Other notable enhancements:
- Improved support for browsers (tested in IE 6, 7 and 8, Chrome, Safari, Opera, and of course Firefox).
- Returning from Preview restores the maximized editor (and in most browsers except IE also when hitting the browser's Back button).
- Reuses the skin styles and integrates nicely with both Albatross and Toucan
Current limitations:
- Because of some IE bugs, the button will appear after a short delay.
- Because of other IE bugs, when exiting full screen the edited field will be displayed a bit larger for about half a second.
- Because of some other IE bugs, when exiting full screen the window will be scrolled to the top of the document (this should be fixed in the next release).
New Live Table UI
The Live Table displaying all documents and all attachments in the Document Index page, as well as Users, Groups and Rights entries in the administration has been extended functionally and revamped from a design and user experience point of view. We have dropped the pseudo scroll bar in favor of a pagination mechanism. Columns are now sortable, which allows for example to sort the document or attachment index by date (ascending or descending).
This Live Table as been made a reusable component, available for applications developers to bind to their application business data in a breathe (just one velocity macro call is enough to create such a table). Read more in the JavaScript improvement section of the release notes, or checking out the live table developer documentation page, that includes a video introducing the table capabilities.
Improved comments UI and functionality
The XWiki comments have also been improved, now allowing users to reply to existing comments, and have threaded discussions. Just click the "Reply" button to respond to any comment.
The comment form will appear under the replied comment.
The data will be sent via AJAX, to improve the continuity and speed.
Comment deletion is also done using AJAX requests:
Multiple attachment upload in one request
Uploading more than one file at once is difficult in web interfaces, since it is impossible to select more than one file in the dialog provided by the browser. It was even more difficult in XWiki, since the user had to scroll down to the attachment area, expand the upload form, browse for a file, submit, wait a lot for the file to be uploaded, and then go back and do all the steps again, several times. We made things a bit easier, by allowing to insert all the wanted files in the form (as distinct file input field), then submit only once.
A first improvement is that the upload form is now expanded by default. You will notice the Add another file and the red X buttons. You can add as many fields as you like (keeping in mind that the wiki has a limit on the total size of the upload data), and you can later remove any field wrongly selected. Pressing the Cancel button will restore the form to its initial state, with only one empty file field.
Another minor improvement related to attachments is that the icons indicating the type of an attachment have been updated to use the Silk set, and more file types visually indicated by specific icons are covered.
New UI for the Class and Object editors
The Class and Object editors have been revamped to improve the usability.
For the object editor, the accordion has been replaced with expandable tree-like structures, with quick buttons for editing only one object at a time, and for deleting an object (which is performed using AJAX, thus much faster, without loosing the context).
To start editing properties, click on the object's name to expand it, click again to collapse it. The same principle be used to expand/collapse classes and object properties (note that for collapsing properties you will have to click on the 
sign next to the property name, since clicking on the property name itself gives focus to the corresponding input field). Using this tree, several objects can be opened at a time, so when you have to edit two objects at the same time, you don't have to continuously move from one object to the other.
A feature that was implemented a long time ago, but remained hidden in the UI until now, is the ability to edit just one object. With the new UI, this feature, which greatly improves the speed when dealing with documents with many objects, is exposed as an intuitive button next to the Delete Object button. Combined with the FullScreen editing support for textarea properties, and with the AJAX Save and Continue, editing large properties inside the wiki is much more productive.
The class editor also underwent major changes. The first thing to notice is that when editing a document that doesn't define a class yet, a list of existing classes is displayed instead of the blank screen from previous versions.
Notice the way classes are grouped by the space they belong to. The same grouping was also applied for the Add Object panel in the object editor, and the Class Switcher panel in the class editor. This separation makes it easier to find the desired class in a wiki with many classes.
Like with the object editor, the class editor also changed the accordion with a tree-like structure. It is now possible to keep more than one property opened at a time, and to collapse and expand only the needed metaproperties.
A major inconvenience with the old class editor was that it was hard to determine the type of a property, without looking carefully at its meta-properties. Now, this is fixed both by listing the type next to the name, and by using a suggestive icon.
Another improvement is that non-functional and rarely used metaproperties have been removed to reduce the perceived complexity of configuring a class, at least until their support will be improved (tooltip, customDisplay, unmodifiable, contenttype). The number property is also hidden when JavaScript is enabled, since the property reordering can now be performed using simple Drag and Drop.
Improved toolbar in the wiki editor
The toolbar for the wiki editing mode has been improved, adding support for the xwiki/2.0 syntax, adding more buttons, and replacing the icons with images from the Silk icon set.
Current limitations:
- When switching the syntax from 1.0 to 2.0, before reloading the document the toolbar for the old syntax is used. This should be fixed in a future release.
Preliminary support for Autosave
A feature frequently asked for is the ability to autosave documents, so that when a problem occurs after a long editing session, at least all but the most recent changes should be recovered. While more changes in the underlying structure of XWiki are needed in order to implement it properly, for the moment we have a preliminary implementation for this feature.
When editing in the wiki mode, you will notice a checkbox allowing to enable the Autosave feature:
By default, a document version will be saved every 5 minutes, but this can be changed by editing the number:
Current limitations:
- The autosave only works with the wiki editor; support for the new WYSIWYG will be added shortly.
- Autosave actually saves the document, creating real versions, so anybody can see the created drafts.
- Each autosave creates a distinct version, so a long editing session with a short autosave interval will create lots of minor versions.
- A new version will be saved even if no changes occurred since the last autosave.
2 PDF export improvements
1.9M2 adds a few important features and addresses several issues related to the PDF export feature:
- PDFs now contain a cover page and a table of contents page.
- Changed the default font to FreeSerif, as it looks better on paper.
- Scaled images preserve the custom dimensions in PDFs also, with the exception that the aspect ratio is always preserved to be the same as the original image, and:
- Images are prevented from overflowing the paper, by being automatically scaled down to the maximum available space.
- The export works when running the container as a user with no home directory, since now the cache is correctly created in the temporary directory.
- A few style changes.
3 JavaScript improvements
We started to cleanup and improve our JavaScript widgets and APIs, to make the code smaller, more modular, more easy to understand, to have a common architecture.
New notifications
XWiki now sends custom events when certain actions occur:
- xwiki:dom:loading and xwiki:dom:loaded when the document is loaded. The former is fired right after the DOM is loaded, and is supposed to be the signal that marks the start of the page's lifecycle. This is the event that should start all scripts making important DOM changes that other scripts should see. The latter is sent right after it, and is supposed to be the signal that triggers most of the scripts loaded at startup. It is recommended to bind startup scripts to this event instead of window.load or document.dom:loaded.
- xwiki:docextra:activated and xwiki:docextra:loaded when loading tabs for the document extra data (attachments, comments, history, etc.). The former is called each time one of the tabs is selected. The latter is called only for the first activation, when the corresponding data has arrived.
- xwiki:actions:cancel, xwiki:actions:preview and xwiki:actions:save are sent when pushing one of the form action buttons. As extra information the second parameter sent to event listeners contains the original click event (if any, and which can be stopped to prevent the action from completing), the form being submitted, and a boolean continue parameter for the xwiki:actions:save event, to distinguish between Save and View and Save and Continue.
Other events will be added in the future as needed.
A complete documentation for those events and their memo data is available on the JavaScript API page on XWiki's platform development guide.
Usage example
Prototype.js is the framework recommended for XWiki development. It eases listening for and sending event using the Event "class" and three new methods for the document object.
To listen for a custom event, do:
alert("The document has loaded");
});
Prototype allows more complicated tricks, like binding to a custom object and registering additional parameters using bindAsEventListener.
To send an event, do:
New reusable components
To support the new UI features, the following new components have been added:
- XWiki.widgets.ModalPopup: a simple modal dialog with no default content, which is supposed to be used as the base class for notifications. See the source code for details.
- XWiki.actionButtons.AjaxSaveAndContinue: as the name says, this is responsible for the improved save and continue functionality. It responds to the xwiki:actions:save event with the continue flag set to true. See the source code for details.
- XWiki.widgets.Suggest: this is the old suggest, for which thorough cleanup work has started. See the source code for details.
- XWiki.widgets.JumpToPage: the first subclass of the ModalPopup, it is responsible for the new Jump to Page feature. See the source code for details.
- XWiki.widgets.LiveTable: the JavaScript class supporting the AJAX Live Table front-end mechanisms, used currently by the Document Index UIs and administration Users, Groups and Rights UIs. You can browse the source code for details, or read the livetable velocity macro documentation for a out-of-the-box macro that can map a live table to an XWiki class of objects.
Cleanup
We started cleaning up the old JavaScript code, replacing custom code with methods provided by Prototype.js, removing unused code, applying a common codestyle, introducing a standard naming convention, introducing a standard directory policy, etc. The first components affected are the Suggest, the behavior for the form action buttons, and the XWiki object itself.
Deprecation strategy
We added a compatibility.js script file that contains deprecated code and aliases from old methods/classes to the corresponding new ones.
4 Switched to UTF-8 as the default encoding
Starting with 1.9M2, the default encoding of XWiki has changed to UTF-8 to better integrate in the multi-national web. If you want to go back to the old encoding, you must edit WEB-INF/xwiki.cfg and WEB-INF/web.xml and change the encoding parameters.
The default HSQLDB database bundled with the standalone XWiki distributions are not affected by the encoding, so they should work after an upgrade without any changes.
5 Mailsender improvements
In 1.9M2 the SMTP setting (username, password, server port, and extra Javamail properties which allow to enable SSL) are easier to configure (now accessible in the Administration -> General tab), and are by default visible in the wiki. Previously, they had to be manually added to the XWiki.XWikiPreferences class. These settings are also used with the registration confirmation email.
Thanks to Guralivu Paul and Lilanne Blaze for providing patches.
Known issues
Common Migration notes
You may also want to import the default wiki XAR in order to benefit from improvements listed above.
