<
From version < 1.18 >
edited by Ecaterina Moraru (Valica)
on 2015/06/15
To version < 1.19 >
edited by Ecaterina Moraru (Valica)
on 2015/06/15
>
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -261,6 +261,61 @@
261 261  <issues specific to the project>
262 262  {{/comment}}
263 263  
264 +== Loading JavaScript from WebJars with RequireJS ==
265 +
266 +[[WebJars integration>>extensions:Extension.WebJars Integration]], available since 6.0M1, allows us to use JavaScript code that has been packaged as JAR and which has been included in the XWiki WAR or installed as an extension. Until this version the URL used to access a resource from a WebJar was looking like this:
267 +
268 +{{code language="none"}}
269 +/xwiki/bin/webjars/resources/path?value=angularjs/1.2.11/angular.js
270 +{{/code}}
271 +
272 +The file path was specified in the query string. As a consequence, if you wanted to load a JavaScript file from a WebJar using RequireJS you would have written:
273 +
274 +{{code language="js"}}
275 +require(["$services.webjars.url('angularjs', 'angular.js')"], function() {
276 + ...
277 +});
278 +{{/code}}
279 +
280 +Note that the **'.js'** extension had to be included because RequireJS doesn't add it automatically if the URL has a query string. Starting with this version, the WebJar URLs look like this:
281 +
282 +{{code language="none"}}
283 +http://<server>/<context path>/webjars/<path/to/resource>[?version=<version>&evaluate=true|false]
284 +{{/code}}
285 +
286 +Note that the resource path is not included in the query string any more. This means you need to update the "require" calls:
287 +
288 +{{code language="js"}}
289 +require(["$services.webjars.url('angularjs', 'angular')"], function() {
290 + ...
291 +});
292 +{{/code}}
293 +
294 +Otherwise RequireJS will attempt to load "angular.js.js". **BUT** note that even with the new URL format there are still cases when the WebJar URLs have a query string: e.g. when the resource must be evaluated. In this case you need to keep the ".js" extension:
295 +
296 +{{code language="js"}}
297 +require(["$!services.webjars.url('org.xwiki.platform:xwiki-platform-tree-webjar',
298 + 'require-config.min.js', {'evaluate': true})"], function() {
299 + ...
300 +});
301 +{{/code}}
302 +
303 +== Mail API changes ==
304 +
305 +The young mail API has been refactored to provide better and more detailed error reporting.
306 +
307 +The MailState enumeration has been extended to report more detailed mail state (##prepare_success##, ##prepare_error##, ##send_success##, ##send_error## and ##send_fatal_error##). The MailListener interface has been extended to provide more detailed event. Now each mail batch should use new independent listener. The listener receive the batch identifier of its own batch when the mail preparation starts (###onPrepareBegin()##), and have to keep it for all subsequent events. Independent success and error events for both the prepare and send phases are provided for each message (###onPrepareMessageSuccess()##, ###onPrepareMessageError()##, ###onSendMessageSuccess()##, ###onSendMessagError()##). Moreover, premature interruption of the prepare phase is caught and reported (###onPrepareFatalError##). Inability of the send phase to retrieve a message for sending is also explicitly reported (###onSendMessageFatalError()##).
308 +
309 +There is now more than one message state representing an error, therefore, the MailStatusResult interface has been extended with a ###getAllError()## method to retrieve all message status in error. Moreover, the ###getTotalMailCount()# may represent a partial total in case of failure of the prepare phase. In that case, it represents the number of mails sent to the send phase. As a consequence, ###isProcessed()# and ###waitTillProcess()# now considerer the batch to be processed when all successfully prepared mail has been sent, or failed to be prepared or sent.##
310 +
311 +The mail API is now tracking individual message based on the standard Message-ID headers, which made it fully compliant with RFC-822 WRT the mail identification. Caller that want to specify custom Message-ID may do so by extending MimeMessage to preserve the Message-ID of the message. Caller is also responsible to ensure that different messages are identified by unique message identifier.
312 +
313 +{{warning}}
314 +Sending multiple messages with the same Message-ID is no more supported since it does not respect the RFC-822 standard.
315 +{{/warning}}
316 +
317 +Reusing the same Message-ID for retrying a failed message is allowed and will be tracked by the same status if the batch identifier is also reused.
318 +
264 264  == API Breakages ==
265 265  
266 266  The following APIs were modified since XWiki 7.0.1:

Get Connected