Version 52.1 by Sergiu Dumitriu on 2009/06/10

Show last authors
1 #startfloatingbox()
2 *Contents*
3 #toc ("2" "4" "")
4 #endfloatingbox()
6 1 Release Notes for XWiki Enterprise 1.9
8 Final version of XWiki Enterprise 1.9 ([Roadmap>enterprise:Main.Roadmap]).
10 1.1 Summary of changes since XWiki Enterprise 1.8.4
12 1.1.1 1 UI improvements
14 This version 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.
16 Many thanks to Marta Gîrdea, who supervised the development of most of these improvements.
18 Quick ~~Jump to any Page~~ navigation
20 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 <tt>Ctrl+G</tt> or <tt>Meta+G</tt> (the meta key is the one between <tt>Alt</tt> and <tt>Ctrl</tt>, 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.
22 {image:jmp1.png}
24 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.
26 {image:jmp2.png}
28 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.
30 {image:jmp3.png}
32 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 <tt>Ctrl+V</tt> or <tt>Meta+V</tt> to view, and <tt>Ctrl+E</tt> or <tt>Meta+E</tt> to edit the target document. ~~Esc~~ simply closes the dialog without changing the current page.
34 {image:jmp4.png}
36 {image:jmp5.png}
38 Known issues:
39 - 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 <tt>Ctrl+G</tt> on Firefox normally searches for the next occurrence of the searched term, but <tt>F3</tt> does the same thing).
40 - The suggest box searches only on the document name. The next release will bring support for quick search by the document's title.
41 - 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.
42 - 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.
43 - 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.
44 - 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.
46 Faster ~~Save and Continue~~ using AJAX
48 Save and Continue doesn't refresh the page anymore, but makes an AJAX request to save the document. When pressing the ~~Save &amp; Continue~~ button, or the <tt>Alt+Shift+S</tt> shortcut, a message appears at the bottom of the screen, indicating that the document is being saved.
50 {image:sac1.png}
52 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.
54 {image:sac2.png}
56 {image:sac4.png}
58 If an error occurs, you will be notified of the problem by a similar notification message:
60 {image:sac3.png}
62 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.
64 Improved ~~Full Screen~~ editing
66 XWiki had a full screen editing mode since 2007, when it was implemented thanks to a [Google Summer of Code>dev:GoogleSummerOfCode.WebHome] student. But it had several limitations that made it less useful than it should have been:
67 - It had a particular look that didn't integrate well with the current skin
68 - It didn't have the action buttons allowing to save or preview the document
69 - It only worked with the main content editor, and only for wiki editing and the old WYSIWYG editor
70 - It had several minor bugs on different browsers
72 {image:fs0.png|The old FullScreen editor}
74 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:
76 {image:fs1.png}
78 {image:fs2.png}
80 {image:fs3.png}
82 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).
84 {image:fs4.png}
86 You can also edit in full screen any textarea in inline mode and in the object editor:
88 {image:fs5.png}
90 Other notable enhancements:
91 - Improved support for browsers (tested in IE 6, 7 and 8, Chrome, Safari, Opera, and of course Firefox).
92 - Returning from Preview restores the maximized editor (and in most browsers except IE also when hitting the browser's Back button).
93 - Reuses the skin styles and integrates nicely with both Albatross and Toucan
95 Current limitations:
96 - Because of some IE bugs, the button will appear after a short delay.
97 - Because of other IE bugs, when exiting full screen the edited field will be displayed a bit larger for about half a second.
98 - 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).
100 New ~~Live Table~~ UI
102 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).
104 {image:livetable1.png}
106 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>platform:DevGuide.LiveTable], that includes a video introducing the table capabilities.
108 Improved ~~comments~~ UI and functionality
110 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.
112 {image:comm1.png}
114 The comment form will appear under the replied comment.
116 {image:comm2.png}
118 The data will be sent via AJAX, to improve the continuity and speed.
120 {image:comm3.png}
122 Comment deletion is also done using AJAX requests:
124 {image:comm4.png}
126 {image:comm5.png}
128 Multiple ~~attachment~~ upload in one request
130 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.
132 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.
134 {image:att2.png}
135 {image:att3.png}
137 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.
139 {image:att1.png}
141 New UI for the ~~Class and Object editors~~
143 The Class and Object editors have been revamped to improve the usability.
145 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).
147 {image:obj1.png}
149 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.
151 {image:obj2.png}
153 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.
155 {image:obj3.png}
157 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.
159 {image:class1.png}
161 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.
163 {image:class2.png}
165 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.
167 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.
169 {image:class4.png}
171 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.
173 {image:class3.png}
175 Improved ~~toolbar in the wiki editor~~
177 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.
179 {image:wt1.png}
181 {image:wt2.png}
183 Current limitations:
184 - 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.
186 Preliminary support for ~~Autosave~~
188 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.
190 When editing in the wiki mode, you will notice a checkbox allowing to enable the Autosave feature:
192 {image:as1.png}
194 {image:as2.png}
196 By default, a document version will be saved every 5 minutes, but this can be changed by editing the number:
198 {image:as3.png}
200 Current limitations:
201 - The autosave only works with the wiki editor; support for the new WYSIWYG will be added shortly.
202 - Autosave actually saves the document, creating real versions, so anybody can see the created drafts.
203 - Each autosave creates a distinct version, so a long editing session with a short autosave interval will create lots of minor versions.
204 - A new version will be saved even if no changes occurred since the last autosave.
206 1.1.1 2 PDF export improvements
208 Some important features were added and several issues addressed related to the PDF export feature:
209 - PDFs now contain a ~~cover page~~ and a ~~table of contents~~ page.
210 {image:pdf1.png}
211 {image:pdf2.png}
212 - Changed the default font to FreeSerif, as it looks better on paper.
213 {image:pdf3.png}
214 - 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:
215 - Images are prevented from overflowing the paper, by being automatically scaled down to the maximum available space.
216 - 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.
217 - A few style changes.
219 1.1.1 3 JavaScript improvements
221 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.
223 New ~~notifications~~
225 XWiki now sends custom events when certain actions occur:
226 - <tt>xwiki:dom:loading</tt> and <tt>xwiki:dom:loaded</tt> 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 <tt>window.load</tt> or <tt>document.dom:loaded</tt>.
227 - <tt>xwiki:docextra:activated</tt> and <tt>xwiki:docextra:loaded</tt> 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.
228 - <tt>xwiki:actions:cancel</tt>, <tt>xwiki:actions:preview</tt> and <tt>xwiki:actions:save</tt> 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 <tt>continue</tt> parameter for the <tt>xwiki:actions:save</tt> event, to distinguish between ~~Save and View~~ and ~~Save and Continue~~.
229 Other events will be added in the future as needed.
231 A complete documentation for those events and their memo data is available on [the JavaScript API page on XWiki's platform development guide>platform:DevGuide.JavaScriptAPI].
233 Usage example
235 [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.
237 To listen for a custom event, do:
238 {code}
239 document.observe("xwiki:dom:loaded", function() {
240 alert("The document has loaded");
241 });
242 {code}
244 Prototype allows more complicated tricks, like binding to a custom object and registering additional parameters using [bindAsEventListener>].
246 To send an event, do:
247 {code}
248"xwiki:mymodule:myaction", {"someParam": true, "anotherOne": myObject});
249 {code}
251 New reusable ~~components~~
253 To support the new UI features, the following new components have been added:
254 - <tt>XWiki.widgets.ModalPopup</tt>: 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.
255 - <tt>XWiki.actionButtons.AjaxSaveAndContinue</tt>: as the name says, this is responsible for the improved save and continue functionality. It responds to the <tt>xwiki:actions:save</tt> event with the <tt>continue</tt> flag set to true. See [the source code>] for details.
256 - <tt>XWiki.widgets.Suggest</tt>: this is the old suggest, for which thorough cleanup work has started. See [the source code>] for details.
257 - <tt>XWiki.widgets.JumpToPage</tt>: the first subclass of the <tt>ModalPopup</tt>, it is responsible for the new ~~Jump to Page~~ feature. See [the source code>] for details.
258 - <tt>XWiki.widgets.LiveTable</tt>: 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>platform:DevGuide.LiveTable] for a out-of-the-box macro that can map a live table to an XWiki class of objects.
260 Cleanup
261 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.
263 ~~Deprecation~~ strategy
264 We added a <tt>compatibility.js</tt> script file that contains deprecated code and aliases from old methods/classes to the corresponding new ones.
266 1.1.1 4 Switched to UTF-8 as the default encoding
268 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 <tt>WEB-INF/xwiki.cfg</tt> and <tt>WEB-INF/web.xml</tt> and change the encoding parameters.
270 #warning("If you were using a database with character encodings in ISO-8859-1, you will have to either switch XWiki back to ISO-8859-1, or convert your databases to UTF8.")
272 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.
274 1.1.1 5 Mailsender improvements
276 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 -&gt; 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.
278 {image:smtp.png}
280 Thanks to Paul Guralivu and Lilianne Blaze for providing patches.
282 1.1.1 6 New Office Importer feature: document splitting
284 The Office Importer application now allows to split documents into multiple wiki pages during import.
286 <img style="border: solid 2px #CCC;" src="$doc.getAttachmentURL("officeimporter.jpg")" />
288 1.1.1 7 XWiki 2.0 Syntax is enabled by default
290 This means that new pages are created using the XWiki 2.0 Syntax and thus benefit from the new WYSIWYG editor too. See [Migration notes for more details>#HDefaultSyntaxchangedtoXWiki20Syntax].
292 1.1.1 8 Other improvements
294 * Document syntax can be changed from the WYSIWYG editor.
295 * Upgraded to Groovy 1.6.3.
296 * Group Sheets are now using the Livetable widget.
297 * Upgrade to Jython 2.5rc3 (used in the Code macro since we're using Pygments for pretty-displaying).
298 * Simple Users don't see technical spaces anymore.
299 * New behavior for Velocity Macro for New Lines and White space (see [Migration notes for more details>#HVelocitymacrocleaning28SyntaxXWiki2029]).
300 * WYSIWYG improvement: Indenting multiple items at once in a list
302 1.1 Known issues
304 * [Bugs we know about>]
306 1.1 Backward Compatibility and Migration Notes
308 #warning("If you're running in a multiwiki setup you'll also need to define the property <tt></tt> to your <tt>xwiki.cfg</tt> file or explicitly name all databases to be migrated as in <tt>,db2,...</tt>.")
310 You may also want to [import the default wiki XAR>Main.Download] in order to benefit from improvements listed above.
312 #warning("Always make sure you compare your <tt>xwiki.cfg</tt> file with the newest version since some configuration parameters were added. Of note, you should add <tt></tt> so that XWiki will attempt to automatically migrate your current database to the new schema. Make sure you backup your Database before doing anything.")
314 1.1.1 Servlet 2.4 compliant container required
316 XWiki 1.8 and earlier were compatible with the 2.3 servlet specification. XWiki 1.9 now requires a servlet 2.4 compliant server to work, please check your container specifications.
318 1.1.1 Default Encoding changed to UTF-8
320 The default encoding was changed from ISO-8859-1 to UTF-8. If you were using the old default encoding and a database using character encodings, you must convert the database data, too, or switch XWiki back to the old encoding
322 1.1.1 Default Syntax changed to XWiki 2.0 Syntax
324 The default syntax is now 'xwiki/2.0' which means that new documents will be created with this syntax.
326 Note that XWiki Enterprise documents (user profile, recent changes, etc) are still using the "xwiki/1.0" syntax, they will be migrated during the 2.0 release cycle.
328 1.1.1 Escaping in parameters (Syntax XWiki 2.0)
330 The syntax for escaping special characters in parameters changed from to ~ to follow the general XWiki 2.0 syntax rule. For example instead of writing
332 {code}
333 {{macro param="val\"ue"/}}
334 {code}
336 to have a quote in the parameter value you will write
338 {code}
339 {{macro param="val~"ue"/}}
340 {code}
342 1.1.1 Velocity macro cleaning (Syntax XWiki 2.0)
344 The velocity content is now "cleaned" before being executed to be able to organize the code in a more readable way. Each group of white spaces and new lines is replace with a single space and you can force a new line or a space with respectively $nl ot $sp. See [code:Macros.VelocityMacro].
346 You can return to no cleaning by setting <tt>core.velocity.filter=none</tt> in <tt></tt> file.

Get Connected