Version 36.1 by Sergiu Dumitriu on 2009/05/06

Show last authors
1 #startfloatingbox()
2 *Contents*
3 #toc ("2" "3" "")
4 #endfloatingbox()
5
6 1 Release Notes for XWiki Enterprise 1.9 Milestone 2
7
8 Second milestone of the XWiki Enterprise 1.9 version ([Roadmap>enterprise:Main.Roadmap]).
9
10 1.1 Summary of changes since XWiki Enterprise 1.9M1
11
12 Main changes:
13
14 * Lots of improvements and new features in the new WYSIWYG editor
15 * Lots of UI improvements
16 * Lots of improvements and bugfixes in the rendering engine and the syntax converter
17 * A new LiveTable widget
18 * Improvements for the PDF export
19 * Started cleanup and refactoring of the JavaScript APIs
20 * Switched to UTF-8 as the default encoding
21 * Upgraded to Velocity 1.6.2
22 * New Dutch translation, improved French translation.
23 * Mailsender improvements
24
25 1.1 UI improvements
26 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.
27
28 1.1.1 Quick ~~Jump to any Page~~ navigation
29 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.
30
31 {image:jmp1.png}
32
33 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.
34
35 {image:jmp2.png}
36
37 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.
38
39 {image:jmp3.png}
40
41 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.
42
43 {image:jmp4.png}
44
45 {image:jmp5.png}
46
47 Known issues:
48 - 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).
49 - The suggest box searches only on the document name. The next release will bring support for quick search by the document's title.
50 - 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.
51 - 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.
52 - 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.
53 - 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.
54
55 1.1.1 Faster ~~Save and Continue~~ using AJAX
56 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.
57
58 {image:sac1.png}
59
60 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.
61
62 {image:sac2.png}
63
64 {image:sac4.png}
65
66 If an error occurs, you will be notified of the problem by a similar notification message:
67
68 {image:sac3.png}
69
70 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.
71
72 1.1.1 Improved ~~Full Screen~~ editing
73
74 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:
75 - It had a particular look that didn't integrate well with the current skin
76 - It didn't have the action buttons allowing to save or preview the document
77 - It only worked with the main content editor, and only for wiki editing and the old WYSIWYG editor
78 - It had several minor bugs on different browsers
79
80 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:
81
82 {image:fs1.png}
83
84 {image:fs2.png}
85
86 {image:fs3.png}
87
88 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).
89
90 {image:fs4.png}
91
92 You can also edit in full screen any textarea in inline mode and in the object editor:
93
94 {image:fs5.png}
95
96 Other notable enhancements:
97 - Improved support for browsers (tested in IE 6, 7 and 8, Chrome, Safari, Opera, and of course Firefox).
98 - Returning from Preview restores the maximized editor (and in most browsers except IE also when hitting the browser's Back button).
99 - Reuses the skin styles and integrates nicely with both Albatross and Toucan
100
101 Current limitations:
102 - Because of some IE bugs, the button will appear after a short delay.
103 - Because of other IE bugs, when exiting full screen the edited field will be displayed a bit larger for about half a second.
104 - 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).
105
106 1.1.1 Improved ~~toolbar in the wiki editor~~
107 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.
108
109 {image:wt1.png}
110
111 {image:wt2.png}
112
113 Current limitations:
114 - 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.
115
116 1.1.1 New UI for the ~~Class and Object editors~~
117
118 The Class and Object editors have been revamped to improve the usability.
119
120 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).
121
122 {image:obj1.png}
123
124 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.
125
126 {image:obj2.png}
127
128 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.
129
130 {image:obj3.png}
131
132 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.
133
134 {image:class1.png}
135
136 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.
137
138 {image:class2.png}
139
140 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.
141
142 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.
143
144 {image:class4.png}
145
146 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.
147
148 {image:class3.png}
149
150 1.1.1 Preliminary support for ~~Autosave~~
151
152 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.
153
154 When editing in the wiki mode, you will notice a checkbox allowing to enable the Autosave feature:
155
156 {image:as1.png}
157
158 {image:as2.png}
159
160 By default, a document version will be saved every 5 minutes, but this can be changed by editing the number:
161
162 {image:as3.png}
163
164 Current limitations:
165 - The autosave only works with the wiki editor; support for the new WYSIWYG will be added shortly.
166 - Autosave actually saves the document, creating real versions, so anybody can see the created drafts.
167 - Each autosave creates a distinct version, so a long editing session with a short autosave interval will create lots of minor versions.
168 - A new version will be saved even if no changes occurred since the last autosave.
169
170 1.1.1 Allowing to ~~upload several attachments~~ in one request
171 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.
172
173 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.
174
175 {image:att2.png}
176 {image:att3.png}
177
178 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.
179
180 {image:att1.png}
181
182 1.1.1 Highlighting the ~~current version in the History~~ view
183 Some users complained that it is not clear that the first version displayed in the history is the current one, and not the previous one (especially since it allows to revert to it). This has now been fixed: the current version is highlighted, and the ~~Restore~~ link was replaced with a proper text.
184
185 {image:his.png}
186
187 Thanks to Chathura Prabuddha for providing a patch for this.
188
189 1.1 PDF export improvements
190 1.9M2 adds a few important features and addresses several issues related to the PDF export feature:
191 - PDFs now contain a ~~cover page~~ and a ~~table of contents~~ page.
192 {image:pdf1.png}
193 {image:pdf2.png}
194 - Changed the default font to FreeSerif, as it looks better on paper.
195 {image:pdf3.png}
196 - 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:
197 - Images are prevented from overflowing the paper, by being automatically scaled down to the maximum available space.
198 - 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.
199 - A few style changes.
200
201 1.1 JavaScript improvements
202 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.
203
204 1.1.1 New ~~notifications~~
205 XWiki now sends custom events when certain actions occur:
206 - <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>.
207 - <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.
208 - <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 <tt>continue</tt> parameter for the <tt>xwiki:actions:save</tt> event, to distinguish between ~~Save and View~~ and ~~Save and Continue~~.
209 Other events will be added in the future as needed.
210
211 1.1.1.1 Usage example
212 [Prototype.js>http://www.prototypejs.org/] is the framework recommended for XWiki development. It eases listening for and sending event using the [Event>http://www.prototypejs.org/api/event] "class" and three new methods for the [document>http://www.prototypejs.org/api/document] object.
213
214 To listen for a custom event, do:
215 {code}
216 document.observe("xwiki:dom:loaded", function() {
217 alert("The document has loaded");
218 });
219 {code}
220
221 Prototype allows more complicated tricks, like binding to a custom object and registering additional parameters using [bindAsEventListener>http://www.prototypejs.org/api/function/bindAsEventListener].
222
223 To send an event, do:
224 {code}
225 document.fire("xwiki:actions:save", {"continue": true, form: this.editComment.form});
226 {code}
227
228 1.1.1 New reusable ~~components~~
229 To support the new UI features, the following new components have been added:
230 - <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>http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/widgets/modalPopup.js] for details.
231 - <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>http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/actionbuttons/actionButtons.js] for details.
232 - <tt>XWiki.widgets.Suggest</tt>: this is the old suggest, for which thorough cleanup work has started. See [the source code>http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/suggest/ajaxSuggest.js] for details.
233 - <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>http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/widgets/jumpToPage.js] for details.
234
235 1.1.1 Cleanup
236 We started cleaning up the old JavaScript code, replacing custom code with methods provided by [Prototype.js>http://www.prototypejs.org/], 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.
237
238 1.1.1 ~~Deprecation~~ strategy
239 We added a <tt>compatibility.js</tt> script file that contains deprecated code and aliases from old methods/classes to the corresponding new ones.
240
241 1.1 Switched to UTF-8 as the default encoding
242 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 <tt>WEB-INF/xwiki.cfg</tt> and <tt>WEB-ING/web.xml</tt> and change the encoding parameters.
243
244 #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.")
245
246 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.
247
248 1.1 Mailsender improvements
249 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 -&gt; General tab), and are by default visible in the wiki. Previously they had to be manually added to the ~~XWiki.XWikiPreferences~~ class. Also, these settings are also used with the registration confirmation email.
250
251 {image:smtp.png}
252
253 Thanks to Guralivu Paul and Lilanne Blaze for providing patches.
254
255 1.1 Known issues
256
257 * [Bugs we know about>http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&&type=1&pid=10010&resolution=-1&sorter/field=updated&sorter/order=DESC]
258
259 1.1 Common Migration notes
260
261 #warning("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")
262 #warning("If you're running in a multiwiki setup you'll also need to define the property <tt>xwiki.store.migration.databases=all</tt> to your <tt>xwiki.cfg</tt> file or explicitly name all databases to be migrated as in <tt>xwiki.store.migration.databases=db1,db2,...</tt>.")
263
264 You may also want to [import the default wiki XAR>Main.Download] in order to benefit from improvements listed above.
265
266 #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>xwiki.store.migration=1</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.")

Get Connected