Home

At least when your JavaScript is not your main business. The strategy we've adopted in XWiki reveals itself somehow similar to the aspects we use to handle deprecation and compatibility of server-side code.

We added in XWiki Enterprise 1.9 Milestone 2 a compatibility.js file to host all deprecated functions and variables, as well as the old aliases of functions that changed signature (renamed, or namespaced for example).

As for the server code, we warn in the (client) console all usages of such deprecated APIs, to help applications developers (and ourselves developers of XWiki Enterprise) move to "the new way". The rule for us is that every release of XWiki Enterprise (including milestones and RCs) should make no use deprecated code (and thus should work fine without the compatibility file).

The very nature of JavaScript makes it easy to implement such a strategy, and in our case no new framework is needed to help achieve that (although some exists, like jquery-aop). Prototype's Function#wrap comes to the rescue! As the doc says, it

distills the essence of aspect-oriented programming into a single method, letting you easily build on existing functions by specifying before and after behavior, transforming the return value, or even preventing the original function from being called.

For example, handling the compatibility of a method that has been moved from the global object to the XWiki namespace only takes the following:

/** Deprecated since 1.9M2 */
window.displayDocExtra = XWiki.displayDocExtra.wrap(
  function(){
    warn("window.displayDocExtra is deprecated since XWiki 1.9M2. Use XWiki.displayDocExtra instead.");
    var args = $A(arguments), proceed = args.shift();
    return proceed.apply(window, args);
  }
);

We can also inject more complex things before the actual call, like DOM manipulation to make the HTML match the new function's expectations. See the live table example in the complete file on fisheye.

This is the first post of what I plan to be a blogging week-end (yes, it's week-end in France already!) I've integrated Guillaume Laforge's Groovy App Engine Web Console as an installable XWiki application, and it feels, well you know… Groovy !

I've added a couple of bindings to allow full access to the XWiki API, and the notion of saved script for recurring admin tasks one would want to execute (and of course, restricted all this to users with programming access level!). Here is a screenshot of the console in action on our incubator wiki, executing a script that empties the trash bin of deleted documents.

The cool thing is that I know I will be using it for real by monday, on a project where I have large imports of data and images to run on a wiki.

The application is available for download on code.xwiki.org.

I will be representing XWiki at the e-Liberatica conference, held in Bucarest the 22th and 23th of May 2009.

I will give a talk focused on enterprise usages of Application Wikis (Also known as "Second Generation Wikis"). My objective will be to attempt answering the following question :

Why, in 2009, you want to use an application wiki as foundation stone of your company's Intranet.

Of course, this taking XWiki as an example (eLiberatica is all about Free and Open Source technologies), but the topic itself is generic.

Today is a special day to me: it's been exactly two years I am working for XWiki, the company - my first real job -, and by extension, two years I've been involved in XWiki, the Open Source project. I'm taking advantage of this event to write down my thoughts about a subject I've been playing with for 2 years now: why, from a personal, selfish point-of-view (so I won't talk about passion here, that's a different topic) one would work in the open ?. By work I mean full-time job bringing food on the table, and by Open Source I mean real Open Source (even when backed by a company).

There are couple of good reasons I had in mind right from the beginning (the Open Source argument was a very strong incentive for me to take the job, I was not addicted to Web technologies at that time, as I probably am now). I still think they are good, valid reasons. Though I think they are arguable and in the end do not make the big difference:

• "You get to work with the best developers out there". My take on this is that you'll find the same talented, maven, developers in the open and in the proprietary world, but it's probably easier and faster to get to work with them in the open. And never forget Peter Norvig's advice:

  "be the best programmer on some projects; be the worst on some others"

• "You are one of the happy few that work on sexy, cutting-edge, software". Well, same argument, I don't think proprietary software programming sucks by essence, there are a lot of sexy software there too ; but might be easier to find this in the open.
• "You get more exposure and recognition for your work". This one is harder to argue with, since working for an Open Source project really means _working in the open_, it's part of the deal. But… it's a double-edged sword ; and there are jobs in the non-open that gives the good exposure as well.

Makes me like my job even more!

I swear I tried! But to be honest, I knew from the beginning it was going to be very hard to just keep that idea in a corner of my head and postpone its realization to an uncertain later future. Let me say it right away, Bespin, from the Mozilla Labs, is much more than just an awesome script editor in your browser! We could go as a far as saying that is it is yesterday's future of an ideal IDE taking shape today on the cloud and with latest in-browser technologies ;)

The editor itself really is a huge thing. It feels so good to write with I knew I could not resist the terrible temptation to plug and make it available to edit XWiki's JavaScript and StyleSheets eXtensions. So I did. Let's be clear, it is a saturday afternoon Q&D hack, not a clean integration, but it does the job. I basically just removed or rewrote some bits in the Bespin.Server class to skip the communication with Bespin server and load and save XWiki's extensions instead, fired automatically a couple of events, et voila! Right now it supports only JavaScript eXtensions, but making it work with StyleSheet ones would be really easy. I only tested it on a recent snapshot of XWiki, but it should work fine with all recent versions. Of course, we can only experience it in browsers that support the canvas element.

Here's how it will look in your wiki :

The XWiki extension is available here. It contains unmodified code from Bespin attached to a XWiki Document. The modified bits (Bespin.Server and Bespin.FileSystem classes) are in a JavaScript extension, human-readable directly from the archive. This extension is licensed under the Mozilla Public Licence, and all Bespin original code (that is, 99.99% of this extension) is the work of the Mozilla Labs Bespin Team.

To use it, just add the following line in the wiki content of a XWiki document that contains a JavaScript eXtension :

#includeForm("XWiki.BespinEditorExtension")

Really, the future is in a <canvas>!

I wrote this article since I actually faced the following issue today, while writing a small and innocent piece of JS. The problem introducing Prototype is that its native object extensions can potentially break other code the page consumes: the other libraries your application relies on, your application own libraries, … actually, even the simplest javascript snippet as shown below. … read the rest

AddSizes.js is a small but powerful Javascript snippet that inspect all the links of certain types that are present in a HTML document (for example office documents, PDFs, media files, etc.) and query their size against Simon Willison's json-head service on Google App Engine. Once it got a response, it inject the information just next to each matched link, so that users know before clicking what type of document to expect, and more, what file size to expect. Here is for example how it can look in a wiki page … read the rest

I moved this blog to the soon to be new default Blog bundled with XWiki Enterprise. A part from the nicer, more "2.0" UI, it has a better category management, and the very valuable possibility to publish later draft articles.

It also makes possible to manage several blogs inside your wiki.

Snapshot of the new blog application are available here. Feedback is more than welcome on XWiki Mailing Lists.

I like services like Pandora, with a huge database and a smart algorithm to help me discover music I am susceptible to like. But it still misses something : the fact that music I am susceptible to like might sound nothing like music I already like. For this I prefer blip.fm - people are very more likely to surprise me with unexpected good tunes than any machine calculus. (And anyway, Pandora is not available for me any longer).

I also like (and still use) last.fm a lot - there are humans in it already - but I find the friendship mechanism not very flexible, and I cannot listen to a stream built on all my friends tastes. For this, I prefer blip.fm, its twitter-like subscription concept (that is: not necessarily symmetric, I don't need to be approved as friend to start listening to someone's music) makes it really easy to build and fine-tune a web radio based on people I trust are going to surprise me the good way.

I subscribe to both friends I know in real life and to anonymous strangers I discover by suggestion or by accident. If I get tired of somebody's blips, I can just unsubscribe from him, and nobody's hurt (well… for people I don't know at least. For my actual friends it does not happen, because… well they are my friends, so they have good music taste ;))

Bonus reasons:

• I can decorate my twits with music
• It's damn simple
• I like receiving props :)

Pass, pass the BLIP !

While looking for examples of integration of java applets in XWiki, I came accross this educational wiki (In Croatian language).

Normala.hr is an initiative of a non-profit organization of teachers of mathematics in Croatia, focused on teaching mathematics in elementary and secondary schools. They use XWiki as a wiki platform, and GeoGebra applets for mathematical concepts illustration. GeoGebra is an Open Source "dynamic mathematics software for schools that joins geometry, algebra and calculus". Look for example at the cosinus function graph (drag the purple point around the circle to draw the function) or the hyperbole construction applet (you can play with the sliders to draw the hyperbole) examples on normala.hr.

The integration with XWiki is very smooth, thanks to the fact XWiki supports plain HTML in its documents. The easiest way to integrate GeoGebra in XWiki is to attach the GeoGebra .ggb file to a wiki document, and use this code snippet to display the applet.

Conclusion : GeoGebra + XWiki = Great combo for educational wikis !