Thursday, May 3rd, 2007

Freja 2.1: XSL and JavaScript

Category: JavaScript, Library

Freja is a specialized JavaScript framework for creating template-based, single-screen web applications. It relies on browser-side XSL Transformation to render the user interface faster than any other Ajax-based method, and is built on top of Sarissa.

This simple example shows inline editing and is explained in this tutorial:


  1. display.behaviors["editLink"] = {
  2.     onclick : function(n) {    
  3.         edit.render(menu, "content", {});
  4.         return false;
  5.     }
  6. };

Posted by Dion Almaer at 6:36 am

4 rating from 26 votes


Comments feed TrackBack URI

Very interesting technique. Sad that Safari requires server-side to help with XSL transformation. Look forward to playing with this a little more to see what possibilities it has.

Comment by mrcritcal — May 3, 2007

How is it the fastest? I mean, it seems all cross platform XSL libs just do a simple switch and let the browser’s engine do the work.

Some hopefully constructive criticism/questions:

I see a Freja.View.ready property. Are you loading both the XML and XSL aynschronously? How do you recommend waiting for both? Can you load a view component syncronously?

Are Freja.View.(get | set) for XSL parameters? Assuming the view is cacheable, how do you clear/reset parameters to the original XSL’s values?

best, -Rob

Comment by Rob Koberg — May 4, 2007

@mrcritcal, WebKit has a XSLT engines and works well with Freja. Hopefully Safari will follow soon.

@Rob… It’s faster compared to using round-trips to the server to retrieve HTML markup, which is what most developers do when using Ajax (xmlhttprequest). And yes, Freja uses the browser’s native XSLT engine.

Yes XML and XSL are loaded asynchronously. There are built-in mechanisms in Freja to defer view rendering until the assests are loaded (hence the .ready property).

There’s no “component” concept in Freja, but you can import XSL templates within XSL templates, so it’s basically the same (never tested it though).

Rendered views are not cached but that an interesting suggestion. For most applications though I’m not sure you would see any significant speed improvement with caching… maybe for complex, very long views.

Comment by cedric — May 4, 2007

OK. I thought it was implying faster than other client side XSL libs.

When I said ‘load a view component’ I basically meant could the XSL file be loaded synchronously. (BTW, you can use xsl:import/include in client side transforms).

I suppose the rendered result would make sense to cache in some cases. For caching, I was talking about the XSL processor/template object. I think it is important if you need to use it more than once. The biggest cost (other than downloading the file) is parsing it into a processor object. That brings up the issue of parameter values passed into the transform. Mozilla type browsers handle it differently that IE. And the methods in either case are not intuitively named. For dojo, I made it so that after each transform the parameters were cleared so the transform is made ‘fresh’. (I thought of it similar to java in that you create a jaxp Templates object that you cache and derive a fresh Transformer for each transform).

Comment by Rob Koberg — May 4, 2007

@Rob, I wasn’t aware that Dojo was using client-side XSLT. Is that part of the new widget system?

Freja creates a new processor object and parses the template each time the view is rendered, so I guess you’re right, there’s room for optimization. The handling of the transformation parameters is taken care of by the Sarissa library. With a previous version of the library, I had to handle parameters differently in IE (basically inserting the parameter values in the XSL template using DOM). Now I don’t have this issue anymore, but since the processor is recreated each time, there’s no need to reset the parameters. I assume Sarissa can do it, but I haven’t tested it.

I’d happy to continue the conversion over email if you want (you can use the contact form on the veerwest site)

Comment by cedric — May 4, 2007

For Safari, here’s one possibility. Safari can’t do JavaScript XSL transforms, but it can do transforms when the XML document has an XML-STYLESHEET directive at the top of the document on page load. I wonder if you can use a hidden iframe that you document.write() the XML plus the XML-STYLESHEET directive at the top into, to force Safari to do the transform? can take a MIME type as the second argument, though most browsers ignore it… I wonder if Safari supports it. You might be able to use this to hack together a client-side JavaScript API on top of Safari using this ability.

Brad Neuberg

Comment by Brad Neuberg — May 7, 2007

Good idea, if that works, Brad. Don’t know if adding the PI to the XML string and document.write’ing to the iframe will trigger the transform, though.

Cedric, did you get a chance to try out Brad’s suggestion?

Another thing along this vein, it is too bad that when using XmlHttpRequest load an XML document with the XSL PI, it doesn’t trigger a transform.

Comment by Rob Koberg — May 11, 2007

Leave a comment

You must be logged in to post a comment.