Javascript

Having just completed one project with extjs, (otherwise known as yui-ext). I thought I would share my thoughts on it.

As a side project, if you liked FlexySvn, my little XUL based Subversion browser, I started playing with a Javascript only version (A single HTML page - no Server / PHP support required):
http://www.akbkhome.com/FlexySvn/templates/test1.html (Firefox only seems to work at present - although I would guess IE fixes should not be to difficult).

This uses XmlHttpRequest's to do roughly the same things that 'svn ls/log/cat' etc. do. - (Done by snooping the packets with Wireshark.). Using Extjs for the interface, and dp.SyntaxHighlighter to do all the syntax highlighting.

This little test does illustrate the key differences between XUL and the Extjs approach.

Ext js advantages/disadvantages

• In-page popups are faster than desktop popups - leading to a snappier interface. (not seen in my svn browser, but a serious issue for other applications)
  
• Interface 'can' work on other browsers, although doing anything complex tends to end up with considerable time taken dealing with IE or Safari bugs.
• Load times are problematic (even stripped down libraries can be a high load if you are offering just a simple form with validation).
• Difficult to see how to have a page degrade nicely for non-js browser - eg. mobile devices.
• extjs bugs tend to be browser specific bugs, and often with things like Safari, which can be exteremly time consuming to fix.
• Defining CSS styles for OL/UL/BODY etc. in the standard css file makes it a bit of a nightmare to work with existing HTML designs.
  

XUL development advantages/disadvantages.

• Single platform make debugging and testing considerably simpler (if it runs in Firefox, it will run everywhere.)
• Interface as XML has a more natural feel to it -  considerably simpler to spot and fix a  layout issue, rather than decyphering a large number of javascript statements.
  
• The approach we used where XUL is served up by PHP, and using frames/pages to react to different sections of the application, make inter-section communication more complex. Compared to a pretty much 'one-page' approach with extjs, which makes managing state considerably simpler.
• Difficult to mix HTML and XUL, using namespaces is klunky, normally we need to use <HTML:everything in here is HTML!>....</HTML> rather than having to ensure we are using XHTML and the namespace.
• bugs tend to be either browser related or security related. - modal dialogs comes to mind...

I have to say that Firebug has been a life saver for the projects I've been doing these last few weeks, and has overtaken the webdeveloper extension at the top of the list of essential extensions.

At the end of the day, When we start a new project that needs an administration system, (non-public), Neither of them offer a perfect solution yet. But I think XUL comes out marginally ahead, given the reduced time spend debugging non-mozilla browsers. (Although the modal windows and popup load times is a serious problem)

For a public front end, I think after some consideration, I will still recommend extjs except where support is needed for mobile devices. And Just hope that I dont get too caught out by IE and Safari's bugs.

View Extended Entry

Posted by in Javascript | Add / View Comments()

We where discussing with one of my clients the idea of including dynamic content on their home page, which is currently static HTML, due to extreme load requirements. Normally Php is only reserved for specific parts of the site, and not on the front page.

I had the idea of using XmlHttpRequest, however another member of the team suggested XSLT, and I have to admit, I've never seen that idea before, and the example he showed basically included content from an external file by just adding a simple tag like
<our:include src="mydynamic.html" part="xxx" />
Where the mydynamic.html could use the 404 handler trick that php.net uses. (eg. if the file doesnt exist, it gets generated by the 404 handler, and deleted by a cronjob every 5 minutes etc.)

My only reservation about this is really that XSLT templates are unreadable garbage. Hence if we ever started to get clever with them, they could quickly become unmaintainable.

This however didnt seem to be a problem so much with XSLT but the fact that reading and writing XSLT files is not particulaly simple. Looking at the Basic specification for 1.0, and the example file he had, it seem clear that this file could easily be generated by a simple tool. However I could not find anything after a quick google search that seemed to exist to do this. So I threw together a simple proof of concept.

What if the template looked more like this:

template("/") {
  applyTemplates;
}

template("*") {
  copy {
     applyTemplates("@*|node()");
  }
}

template("processing-instruction()") {
  copy {
     applyTemplates("@*|node()|text");
  }
}

// make h1 green

template("html:h1")
{
  copy {
     attribute("style") <colour:green>
     applyTemplates("@*|node()");
  }
}

template("our:include")
{
   variable("part", "@part");
   applyTemplates("document(@src)//*[@id=$part]");
}

Writing a simple parser generator in D, enabled the generation of the xslt file from this file.

Compile parser generator:

dmd xsltgen.d -of/tmp/xsltgen -od/tmp

Convert the above file to xslt:

/tmp/xsltgen inctest.xslts

And magically you have a generated file, and a maintainable version.. - Makes me wonder though, has someone done this already?

the source: xsltgen.d
output from the above example: inctest.xslt

View Extended Entry

Posted by in Javascript | Add / View Comments()