[Helma-user] Prototype, JQuery, ExtJS Rendering in Helma

[Joshua Paine]

Philip Weaver wrote:
> Has anybody taken steps rendering pages using any of these sort of 
> frameworks within Helma and returning as a response instead of using 
> skins? Prototype, JQuery, ExtJS, or any other...

I'm only really familiar with jQuery, but it doesn't seem suited to 
composing whole pages. The only benefit you really get over templates 
for page composition is being able to reach into the DOM and modify it, 
but you have to do it with basic string concatenation and no automatic 
escaping, etc.. I think it would get ugly fast.

I've been doing something else, though. Firefox's JavaScript engine and 
Rhino (the Java JavaScript engine Helma uses) both support a JavaScript 
add-on standard called E4X (ECMAScript For XML) that makes XML a native 
datatype in JavaScript--sort of like Regular Expressions in that the 
syntax is integrated right in even though it seems a little odd in the 
C-like style of the rest of JavaScript.

I wrote the following introduction in response to someone's blog post 
about the Helma tutorial:
----------------------------------
FWIW, I did the Helma tutorial and thought that the part where you add 
macros to root to keep this.firstname, etc. from breaking 
<http://helma.org/docs/tutorial/hopobject/> was one of the ugliest 
things I had ever seen.

I'm not sure what the right solution is when using skins, because I've 
dropped them. (See the end, though.) I'm doing my view code in 
JavaScript via E4X.

E4X brings XML into JavaScript as a native syntax/datatype. E.g.,

var b = <b>something bold</b>;

Is legit code.

More importantly,

var displayName = <b>{req.data.username}</b>;
var welcome = <p>Welcome, {displayName}!</p>;

is not only legit but always does the right thing. That is if 
req.data.username="<i>XSS!</i>", welcome.toXMLString() returns:

<p>Welcome, <b>&lt;i&gt;XSS!&lt;/i&gt;</b>!</p>

Tada! Automatic XSS protection all the way through. With Helma skins 
(and so many other templating technologies) you have specify what kind 
of escaping you need, and the default is no escaping (unsafe!).

And with E4X, the fix for this.firstname breaking when the skin is used 
by root is just to write the E4X "skin" this way:

<input name="firstname" value={this.firstname || ''} />
----------------------------------
That's just one of the good things, really, and perhaps not the part 
you're most interested in if the client-side script libraries looked 
appealing. Assuming that you have an E4X XHTML document stored in var 
html, here are a couple of other things:

html.head.title // the title tag
html..h1 // all h1 tags in the doc
html..form.(@method=='post') // all forms with method="post"

And it handles namespaces well, too if you want to go there.

There are a few warts, too. The most trivial is that the snapshot of 
rhino that helma 1.6 uses has a bug with attributes in E4X (e.g., the 
form value example won't work). You'll want to get the updated rhino.jar 
from helma SVN. But there are a few other problems with E4X, apparently 
indicative of some folks on the committee having no idea that you might 
want to use the thing for actual work in the actual world. E.g., there's 
.toXMLString(), but no .toXHTMLString() or .toHTMLString(), so there are 
a few tricky spots in getting output that will actually work when served 
with an HTML content-type. And there are two versions of the spec: the 
ECMA one, and the ISO one. The ISO one changes how member access works, 
so my last form example will throw an exception if you have any forms in 
the document without a method attribute specified. Brendan Eich has 
publicly said he thinks the original ECMA way is braindead--for once I 
think he's off base and the modified ISO way is the stupid one. Firefox 
supports the ISO style; Rhino fortunately supports the ECMA.

There's a few other things that would be nice to have in E4X that aren't 
there (e.g., functional-style access to element collections), but 
those're the biggest issues I've found.

And in fairness to the built-in templates, I've since learned that you 
can set an unhandledMacro handler to, e.g., return '' that would obviate 
the outdated instructions in the tutorial to create one macro per 
property you access in the skin. That's better, but still ugly IMO.

See:
<http://developer.mozilla.org/presentations/xtech2005/e4x/>
and
<http://developer.mozilla.org/en/docs/E4X>

for more E4X info, but some details I was only able to figure out by 
reading searching through the PDF spec linked toward the bottom of the 
latter page.

-Joshua