Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -1,6 +1,6 @@
1	1	#startfloatingbox()
2	2	*Contents*
3		-#toc ("2" "3" "")
	3	+#toc ("2" "4" "")
4	4	#endfloatingbox()
5	5
6	6	1 Release Notes for XWiki Enterprise 1.9 Milestone 2
...	...	@@ -21,11 +21,11 @@
21	21	* New Dutch translation, improved French translation.
22	22	* Mailsender improvements
23	23
24		-1.1 1 UI improvements
	24	+1.1.1 1 UI improvements
25	25
26	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	27
28		-1.1.1 Quick ~~Jump to any Page~~ navigation
	28	+1.1.1.1 Quick ~~Jump to any Page~~ navigation
29	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	30
31	31	{image:jmp1.png}
...	...	@@ -52,7 +52,7 @@
52	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	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	54
55		-1.1.1 Faster ~~Save and Continue~~ using AJAX
	55	+1.1.1.1 Faster ~~Save and Continue~~ using AJAX
56	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	57
58	58	{image:sac1.png}
...	...	@@ -69,7 +69,7 @@
69	69
70	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	71
72		-1.1.1 Improved ~~Full Screen~~ editing
	72	+1.1.1.1 Improved ~~Full Screen~~ editing
73	73
74	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	75	- It had a particular look that didn't integrate well with the current skin
...	...	@@ -105,7 +105,7 @@
105	105	- Because of other IE bugs, when exiting full screen the edited field will be displayed a bit larger for about half a second.
106	106	- 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).
107	107
108		-1.1.1 Improved ~~toolbar in the wiki editor~~
	108	+1.1.1.1 Improved ~~toolbar in the wiki editor~~
109	109	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.
110	110
111	111	{image:wt1.png}
...	...	@@ -115,7 +115,7 @@
115	115	Current limitations:
116	116	- 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.
117	117
118		-1.1.1 New UI for the ~~Class and Object editors~~
	118	+1.1.1.1 New UI for the ~~Class and Object editors~~
119	119
120	120	The Class and Object editors have been revamped to improve the usability.
121	121
...	...	@@ -149,7 +149,7 @@
149	149
150	150	{image:class3.png}
151	151
152		-1.1.1 Preliminary support for ~~Autosave~~
	152	+1.1.1.1 Preliminary support for ~~Autosave~~
153	153
154	154	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.
155	155
...	...	@@ -169,7 +169,7 @@
169	169	- Each autosave creates a distinct version, so a long editing session with a short autosave interval will create lots of minor versions.
170	170	- A new version will be saved even if no changes occurred since the last autosave.
171	171
172		-1.1.1 Allowing to ~~upload several attachments~~ in one request
	172	+1.1.1.1 Allowing to ~~upload several attachments~~ in one request
173	173	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.
174	174
175	175	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.
...	...	@@ -181,7 +181,7 @@
181	181
182	182	{image:att1.png}
183	183
184		-1.1.1 Highlighting the ~~current version in the History~~ view
	184	+1.1.1.1 Highlighting the ~~current version in the History~~ view
185	185	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.
186	186
187	187	{image:his.png}
...	...	@@ -188,7 +188,7 @@
188	188
189	189	Thanks to Chathura Prabuddha for providing a patch for this.
190	190
191		-1.1 2 PDF export improvements
	191	+1.1.1 2 PDF export improvements
192	192
193	193	1.9M2 adds a few important features and addresses several issues related to the PDF export feature:
194	194	- PDFs now contain a ~~cover page~~ and a ~~table of contents~~ page.
...	...	@@ -201,11 +201,11 @@
201	201	- 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.
202	202	- A few style changes.
203	203
204		-1.1 3 JavaScript improvements
	204	+1.1.1 3 JavaScript improvements
205	205
206	206	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.
207	207
208		-1.1.1 New ~~notifications~~
	208	+1.1.1.1 New ~~notifications~~
209	209
210	210	XWiki now sends custom events when certain actions occur:
211	211	- <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>.
...	...	@@ -213,7 +213,7 @@
213	213	- <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~~.
214	214	Other events will be added in the future as needed.
215	215
216		-1.1.1.1 Usage example
	216	+1.1.1.1.1 Usage example
217	217
218	218	[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.
219	219
...	...	@@ -231,7 +231,7 @@
231	231	document.fire("xwiki:actions:save", {"continue": true, form: this.editComment.form});
232	232	{code}
233	233
234		-1.1.1 New reusable ~~components~~
	234	+1.1.1.1 New reusable ~~components~~
235	235
236	236	To support the new UI features, the following new components have been added:
237	237	- <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.
...	...	@@ -239,13 +239,13 @@
239	239	- <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.
240	240	- <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.
241	241
242		-1.1.1 Cleanup
	242	+1.1.1.1 Cleanup
243	243	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.
244	244
245		-1.1.1 ~~Deprecation~~ strategy
	245	+1.1.1.1 ~~Deprecation~~ strategy
246	246	We added a <tt>compatibility.js</tt> script file that contains deprecated code and aliases from old methods/classes to the corresponding new ones.
247	247
248		-1.1 4 Switched to UTF-8 as the default encoding
	248	+1.1.1 4 Switched to UTF-8 as the default encoding
249	249	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-INF/web.xml</tt> and change the encoding parameters.
250	250
251	251	#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.")
...	...	@@ -252,7 +252,7 @@
252	252
253	253	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.
254	254
255		-1.1 5 Mailsender improvements
	255	+1.1.1 5 Mailsender improvements
256	256	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. These settings are also used with the registration confirmation email.
257	257
258	258	{image:smtp.png}