Wednesday, February 29, 2012

Quickly search code on GitHub with Chrome

You're looking at a project on GitHub, say Orbeon Forms, and would like to do a search in that project. GitHub provides a search field, but it searches through everything on GitHub, not just the current project you're looking at. This unless you click on the Advanced Search icon, in Search for select Code, and prefix your search by repo:orbeon/orbeon-forms. If you're anything like me, you'll find this too time consuming and won't use the GitHub site for searching.

Luckily, if you're using Chrome, there is a shortcut. With that "shortcut" in place, type o hello world in the location bar, and you'll see:

Press enter, and you'll get the results from GitHub. Now that is something I'd use! All you need to do:

  1. Go to the Chrome settings (⌘, on OS X).
  2. In the Search section (shown below), click on Manage Search Engines.

  3. Scroll to the very bottom of that dialog to add a new entry. In the first field enter a descriptive name, say Orbeon Forms source. In the second, the keyword you'll use as a prefix when doing a search, say o for Orbeon. (You can pick a more descriptive keyword, but I'm in a rush, so o it is.) Finally, the last field put:

    Note the orbeon%2Forbeon-forms in that URL, which you can change if you'd like to search another GitHub projects. With this, your new custom search engine will look like:


Wednesday, February 15, 2012

An improvement to inline JavaScript in actions

We just implemented a performance enhancement when using JavaScript from XForms, in particular from XBL components.

In Orbeon Forms, you typically call client-side JavaScript from actions with the <xxf:script> extension action or with <xf:action type="javascript"> (which is now the preferred way). For example, the Currency XBL component has a call like this:
Until now if  you used more than one instance of the currency component in your page, the inline scripts would be duplicated multiple times on the client.

Now, with this enhancement, each script body is associated a SHA1 hash based on its content, and a given script body is sent to the browser only once. This means less duplication of code.

Here is the documentation on <script> and <action> actions for scripting. And if you are interested in the implementation, here is the git commit, in particular PartEventHandlerAnalysis.scala.

Tuesday, February 14, 2012

Does XForms need to be implemented natively in browsers?

For as far as we can remember, we've been getting variants of the following question: "Does XForms, as a technology, really have a future? I wonder, as I don't see browsers making any moves to implement it."

When considering technologies, it is reasonable to worry about their future. But why would one think XForms has no future if it isn't implemented in browsers?

In the late 90s and early 2000s, XML technologies were widely imagined to be the foundation on which future web apps would rely. As part of that vision, browser vendors implemented XML parsing, XPath, XSLT transformations, and even CSS styling of XML documents. XForms too was initially designed to nicely fit in that stack.

For better or for worse, that XML-centric vision didn't come to fruition. This in particular means that initial efforts to bring XForms to the browser natively have been abandoned. Instead today's browsers mostly eschew XML and implement improved, faster and more robust versions of the technology stack we had 10 years ago: HTML, CSS, the DOM and other JavaScript APIs, and of course JavaScript itself.

In short, in the browser, JavaScript has won and XML has lost, as part of the native browser stack. It might be disappointing to some, but at Orbeon, we recognized this many years ago. In 2005 already we implemented the first version of our Ajax-based XForms engine, which shipped in Orbeon PresentationServer 3.0.

So the native XForms ship has sailed a long time ago in our opinion. Instead, the web browser has increasingly shown to be a great platform to build all sorts of application and frameworks, and XForms happens to be just one such technology.

This situation in fact has great benefits: nobody waits for browser vendors or all web users to upgrade their browsers to use a newer version of jQuery or Ruby on Rails. So not being a native browser technology allows us to move faster, and you to benefit from improvements sooner (proof: the Orbeon Forms engine still works in IE 6!). It also allows Orbeon to implement a split architecture, where data can reside on the server, while logic run on either the browser or the server, depending on what is the most appropriate.

And what about HTML5 forms? Do HTML5 forms mean that XForms is no longer needed? HTML5 contains welcome incremental improvements over what is available in HTML 4: if you are creating very simple forms, HTML forms and a bit of JavaScript will be just fine. Where XForms has a big edge is for creating complex forms, maybe with sophisticated validation logic, or to manage a large number of forms. And needless to say, if you already deal with XML data, XForms will be a perfect match.

Wednesday, February 8, 2012

Orbeon Forms 3.9.1 PE released

We are happy to announce the release of Orbeon Forms 3.9.1 Professional Edition (PE).

This release is a stable update to Orbeon Forms 3.9.0 PE. It includes over 40 bug-fixes and select low-risk features. For more information, see the full list of changes.

Orbeon Forms 3.9.1 PE is available immediately from the downloads page.

Wednesday, February 1, 2012

New TinyMCE rich text editor, with iPad support

Orbeon Forms has supported rich text editing for the longest time, leveraging the YUI 2 RTE. However, depending on your situation, the RTE isn't always the best editor. For instance, it doesn't support <p> and instead uses <br>, by design. Also, it can't be use on iPads and iPhones, despite iOS 5 now supporting HTML5's contentEditable. For this reason, we created a new component, which uses the TinyMCE WYSIWYG editor, with the thebigreason skin.

For more details, see the TinyMCE component documentation.  Our thanks go to Teleflex, who sponsored the development of this component, as well as Florian Schmitt, who contributed a first implementation.