 OK, so you didn't hear anything. Anyway, I can do it without. So hi, I'm Manka from Xwiki. I'm here with a gang to show you our new wizard editor. And I have a clock restarted. Yeah. So how many of you have ever heard of Xwiki up to now? Well, cool. How many of you have played with Xwiki up to now? Almost as much. So for the rest of you, Xwiki is a leading enterprise wiki platform. It's written in Java. It's distributed under the LGPL license. And it has been started in 2003. And we've been coding on it since. The community is 14 active committers. There's more of them, but sleeping. Over 700 subscribers to our mailing list and of my last knowledge, over 10,000 downloads per month. There's more information there about us. You can go and check it out. And the WizzyWig team is not me working on the new WizzyWig. It's a whole team. Mario's struggling back home probably just as we speak. So we're here to show you our new WizzyWig editor, which is written in GWT, which we have built for wiki and to share it with the world. So of course, now probably half of you are going to leave the room because, oh, no, you're at another WizzyWig editor. But why did we actually need it? Because we needed quality, we needed control, and we needed extensibility. There already are a couple of good editors, as you all might know, which provide very nice quality, valid HTML, lots of features, very good job done, cross-browser development, and cross-browser editing, very good output, and everything. But we also needed a bit of control to that. We don't just need a very nice HTML and very nice features if we cannot control the HTML that is generated from these features. We need to be able to manage exactly what is the HTML generated and to manage the HTML that we get as an input when we want to edit. We needed that because we're wiki, and we need to transform all that into wiki syntax. And that can become a very tough job if you cannot control the HTML closely. We also needed extensibility for that. It's not enough to have control. You can have control, of course, if you go to the browser level. But we needed a higher level to develop, to be able to code high-level plugins and features. For example, we wanted our editor to be real-time, concurrent editing. You cannot do that if you go very low level. It's just impossible, because there's a lot of things that you need to do. And low level, it's way too much struggling to do that. So as you all know, there's a very much mess around this layer. You have a lot of browsers, all of them doing the job just the way they feel to, in read mode. So if you try to read the web page, if you try to read the download web page, it's already high enough. And if you try to edit it, I can tell you it's way, way, way harder. And the way we see this is with an abstraction layer. So you have the browser mess down here and an abstraction layer with the good APIs that show you what's in there and what is the action, what are things happening, what is the user doing, what is it doing, how is it doing, and stuff like that, which allow you to control the content being edited with an abstraction layer. This abstraction layer is very important because if it's flat as I draw it here and the way we're trying to build it, then it will allow you to implement logic above the layer, like the plugins or the command extensions, without caring about browser implementations, without caring about browsers at all. The way current editors are doing this job is they go up from the logic, they discover a browser incompatibility bug kind of stuff, and they go down here, fix it, and up again to the logic. This is very, very not easy to handle when you're coding high level because you don't know what is at the browser level. So if you have this abstraction layer, you're able to implement your logic regardless of the browser things. For example, you can think of this layer because what JavaScript libraries provide for you today, like jQuery or Prototype, they provide an API to handle the DOM in the browser independent, of course. We do that for the edit mode. And this range API, this W3C range API that we implemented in GWT to help us, it's something that was never done before, actually. We did it and we did it quite good and we're actually thinking more about it. OK, so how did we do our nice editor? We did it in GWT. Why did we do it in GWT? Because so for those who don't know what GWT is, it's a Google World Toolkit. It's a framework for developing JavaScript applications in Java from Google, which basically compiles Java into JavaScript code. All the coding you do, you do in Java and everything is compiled into JavaScript browser independent browser, cross browser compatible code. So this is very nice because you have all the advantages of the Java language. You have the strong type Java, which gives you, for example, it gives you the errors that compile time and not the throne time, which can be very important. You have all the tools that come with Java, IDEs, build tools such as Maven and test tools, such as JUnitTestCase or things like that, JUnitTestSuits or things like that. GWT also comes with a very nice cross browser development support, which means that not only that is built to be compiled cross browser, but it also provides you a mechanism in which you can do your own cross browser development. For example, you have a class or interface and you have different implementations for various browsers, which can prove to be very useful because you don't have ifs anymore. If browser equals something, then do this. If browser equals something, all your browser-dependent code, if any, is localized, which is very nice. It's localized in a single class, which is very nice. There's also the GWT RPC mechanism for asynchronous calls, which is basically a remote procedure call mechanism through which you do Ajax calls. And there's also the libraries that come with GWT. Either it's GWT-built libraries or the JavaScript libraries that can take a GWT wrapper. I think most of you don't really care about this slide or don't want to know anything, so don't want to know all of it. So I'm going to just take an example and show you how our editor works. So for example, the build feature in a WYSIWY editor. For browsers allow editing content, editing HTML through the command mechanism. So basically, you have an HTML and you tell the browser to execute a command. Just this way, the build is a command that you tell the browser to execute. The problem is that the browser has executed the way they know to do it. For example, some of them generate B tags, some of them generate the strong tag, and you actually want to control that. You want to do that in a single way regardless of browser. So you implement the build feature as a plug-in. As a plug-in. So the plug-in will add its build button in the editor toolbar. It would listen to the edited DOM to get the information about how the DOM looks like and where the user is actually applying it. So because when you do build, you need to know where the user is. You need to know what is the text that you need to make bold, right? That's what the DOM and RAGE API that I told you earlier allow you to do, allow you to know what is in there and what is the user doing with it. So the plug-in knows where the user is. Now, how will this plug-in actually execute the bold action that we mentioned in a browser-independent way? It would do it through this mechanism, through the command manager and a specific command. Well, actually the default browser command that we overridden. This command manager allows to create, to provide new implementation for default browser commands or to create new custom commands. And the plug-in can do that. The plug-in has access to this command manager. You can, a plug-in can tell the command manager, okay, whenever bold is executed, execute this, what I tell you and not the browser default, which is very cool. So the plug-in asks the command manager to modify the actual edited document. So what's really nice in this whole architecture is the fact that plug-ins have access to the content being edited through the download page API, which is the right level of API, and they also have access to the commands. They can create new commands or they can overwrite existing commands. They can use them and they can know when they have been executed. So, what we want to do, I want to do it, but have you done it yet? So, right now we're supporting Firefox 2 and 3 and Internet Explorer 6 and 7. We have finished the browser independent abstraction that I was talking about earlier, this one here. So this layer is actually finished for Firefox 2 and 3, Internet Explorer 6 and 7. You can code your plug-ins and commands on top of it with no thought whatsoever about the browsers. Okay. Very HTML generated by the browser. We're almost there. It's almost done. There are just a few things that have left to be fixed. And the plug-ins, the plug-in built is in progress. The general purpose plug-ins are almost there and we're working on the XFiki plug-ins. Some of the plug-ins we're working on are the concurrent real-time editing that we were trying to build, the office import. These are just a few examples of the high-level plug-ins that you can build with this architecture. What is, so what are we trying to do next? We have a few issues left on the general purpose of the WISI week, so just a few bugs on the WISI week editing. The general purpose one, not the XFiki specific one. We have a lot of features for XFiki's usage that we have one to finish until March because we have a nice release then. We need to take care of the other browser support and at the beginning of the summer we plan to promote this project as a top-level project to externalize it out of the XFiki code base and have it available for the community, have it fully as a standalone WISI week editor. Right now it is built with this in mind but it's not really quite there. We have a little bit of work, okay. So about this thing, I wanted to, this thing is actually not really that difficult because, so what would mean to add a new browser support? What's very, very nice about this architecture is a new browser support does not mean you have to go in the logic and change the logic to support your new browser. You just have to provide this API because your whole logic is built on top of this abstraction layer and if you want to support a new browser, for example, Safari or Chrome or whatever, you just have to provide this API and all your plugins, all your commands are going to work afterwards with no problems. So, maybe someone actually thought about wanting it after my talk. It is bundled with 171 and higher releases of XFiki and it's going to become the default editor in the next releases. If you want to contribute, if you want to help us to do it, as I said, it's planned to become a top level project. You can get it from our SVM right now as we talk. You can play with it and help us on our bug tracker. That would be really, really nice and you can always provide patches and create plugins. Okay. Questions? Anyone? Okay. Because that's how GWT works, actually. We'll talk after, we're here with the game.