Rhino 1.6R6 with E4X fix and patches for Helma

Rhino 1.6R6 has now been released . The older Rhino jar that is part of the current Helma 1.6 package contains a E4X bug that prevents attribute support from working properly. To use E4X with Helma, you therefore need to replace that jar with the newer version.

While all Helma related patches that were pending at the time have been committed to Rhino 1.6R6 in June, there since has been one more Helma related patch that didn't make it into the Rhino 1.6R6 release version.

So, here's a version of the Rhino 1.6R6 containing that E4X fix and the pending Helma related patch:

http://helma.zumbrunn.net/downloads/rhino16r6patched/rhino.jar

With that patched version placed at ./lib/rhino.jar of your Helma installation, you can now enjoy E4X in your server-side Javascript and for example turn your skins into XML objects. With the code below, you could then access a skin "foo.skin" as XML object using this syntax: this.views.foo

/**
 * Object containing the collection of available views
 * 
 * @type Object
 */
Mocha.prototype.__defineGetter__('views',function() {
    var views = {};
    var protos = this.getPrototypeChainAsNames();
    var that = this;
    for (var proto in protos) {
        for (var skin in app.skinfiles[protos[proto]]) {
            if (!views[skin]) {
                views.__defineGetter__(skin,
                function(){ 
                    var s = skin; 
                    var obj = that; 
                    return function(){ 
                        return new XML(obj.renderSkinAsString(s)); 
                    }; 
                }());
            }
        }
    }
    return views;
})

/**
 * Returns the prototype chain as a string array of prototype names
 * 
 * @return Array
 */
function getPrototypeChainAsNames(){
    return this.getPrototypeChain().map(
                function(proto){ 
                    return / (\w+)\]$/(proto.toString())[1];
                });
}

/**
 * Returns the prototype chain as an array
 * 
 * @return Array
 */
function getPrototypeChain(){
    var protoChain = [];
    var proto = this.__proto__;
    do {
        protoChain.push(proto);
        proto = proto.__proto__;
    }
    while (proto != Object.prototype)
    return protoChain;
}

Helma 1.6 is ready!

Go grab it here! This release makes building server-side applications with Javascript more powerful and more flexible than ever.

See the change log for a full overview of all the enhancements. Highlights include support for getters/setters and E4X with the new Rhino 1.6, subskins and macro pipes/filters as additions to the skin rendering framework , and various new HTTP-related features .

Have fun exploring this Helma release and we hope you'll share your experiences with us on the mailing list and the IRC channel .

Junction brings Rhino on Rails to Helma

Steve says he switched the server-side implementation of Trimpath Junction to run on top of Helma . So, using Steve Yen's Junction, we'll soon have Rhino on Rails running as a Helma app.

What is this now? Junction on Helma? Or Helma on Junction? My head is spinning. Well... Rhino on Rails, anyway :-)

Javascript for Java programmers

Maksim Lin wrote a nice introduction to Javascript for Java programmers . I think that's exactly how the Helma documentation has to introduce people from different backgrounds to the basics of Javascript, and then continue on to the concepts of Helma.

The server-side advantage

Many web developers that have only worked with Javascript on the client-side seem to forget that the limitations they are used to inside the web browser and the DOM, do not apply when using Javascript on the server-side. For example, with Helma on the server-side, you can make use of any Java libraries. There is probably no language that has a wider range of available libraries. To instantiate an object from a Java class in Helma you could simply use something like:

var foo = new Packages.com.bar.util.Foo()

On the server-side you are in control of the environment in which your application runs, which means you do not have the compatibility issues you are used to from the web browser. Also, you do not need to wait for new technology to be adapted by the user community. So, on the server-side you can always make use of the latest Javascript features. For example, you can use E4X because you would know that your server-side environment supports that.

Another example is being able to extend the Object and Array prototypes without worrying about breaking for/in loops, like is currently the case on the client-side. That ability alone allows you to bend Javascript in the directions of your preferred coding style and makes it incredibly flexible.

What you can’t change, of course, is the curly braces syntax. But I think the fact that it shares that syntax with the two big languages C and Java is ultimately Javascript’s big advantage that makes it a good companion in these environments.

John Resig on Javascript as a language

In his JavaScript as a Language blog post, John Resig writes that Javascript is ready for its next phase, breaking out from its traditional habitat inside the web browser. In this regard, he thinks two projects have really stood out as having a lot of potential. Rhino on Rails and Helma.

John says about Helma: "This web application framework is a long standing stalwart of server-side development with JavaScript (again, using Rhino). Surprisingly, it’s managed to fall through the cracks with just about every JavaScript developer that I know. I recently noticed it, and after some startup friends of mine revealed that they’re developing an application based on it, I became convinced that we’ll be hearing about this little framework in the upcoming months."

Of course, Javascript has been used on the server-side in many products ever since Netscape used it in its server-side offerings. What makes Helma special, is that it is for "Javascript as a Language" what Django is for Python and what Rails is for Ruby. In fact, Helma probably was the first Rails-ish web framework, offering an agil development approach and code-less mapping of objects to database tables, long before there even was such a thing as Rails.

At the time of Helma's first release the problem was that Javascript was deep in its dark age. Hardly anybody took Javascript seriously as a language. In 2001, the manifestos for a Javascript enlightenment were already in place, though. David Flanagan released the fourth edition of his Rhino book, which cleanly separated the core Javascript language from the client-side Javascript and Douglas Crockford wrote his now famous "Javascript: The World's Most Misunderstood Programming Language" web page, but not many noticed.

Back then, I thought that Javascript was so much stuck in browser-centric preconceptions that we could never redefine what "Javascript" was perceived as and that we should switch to using the language's original project name "Mocha" when talking about it outside the web browser. Later, the Ajax hype came along and proved that it is possible to redefine the way the language is perceived. Generally, Javascript is still seen as a client-side language, but I think we know now that this can change quickly :-)

Rhino on Rails

Steve Yegge has posted more details on his port of Rails to Rhino and his thoughts on Rhino.

"When you start digging into Rhino, you find unexpected depth. JavaScript (unlike Perl, Python and Ruby, at least today) actually has a real specification, and Rhino follows it rigorously, aiming for complete SpiderMonkey compatibility within the bounds allowed by the different language platforms. Rhino also offers rich configurability, has well-defined multi-threading semantics, has a full set of hooks for debugging and profiling, and much more besides. There's a lot under the hood."

About building on Rhino, he says... "keep in mind that this is server-side JavaScript we're talking about, and on the JVM to boot. So libraries aren't an issue; there are plenty. And browser incompatibilities aren't an issue either - there's only one Rhino, and it works as advertised. But we've been able to go a step further and make some fundamental extensions that have made it almost Ruby-esque."

Interestingly, the example he picks is regarding the enumeration of methods and properties extending the Object and Array prototypes... "in client-side JavaScript there's currently no way to define a property that's non-enumerable, which implies that you can't add new functions or properties to Object.prototype, since they'll suddenly start showing up in your object literals (which are JavaScript's hashes, more or less). But in Rhino you just create a Java method that calls into the Rhino runtime to define non-enumerable properties, and you can extend Object.prototype to your heart's content. So we went wild, and added pretty much every interesting Ruby (and Python) built-in method on the built-in classes (Object, String, Array and the like)."

Of course, with the dontEnum method the way it's implemented in Helma, you can additionally also do this in plain Javascript. (Did this feature make it back into Rhino with the Helma patches Norris Boyd recently committed ? Not sure.)

Steve Yegge says that quite a team inside of Google has gathered by now, investing their 20% time into future Rhino development. Very Cool! I think that's probably the best news about the whole story - because on the Rails port side of the story, it seems he didn't really address the most interesting part, ActiveRecord, and they are instead planning to go in the direction of Hibernate.

He makes it clear that the project is not at a stage where it could be open sourced, and that that won't change much for at least a year. It looks like they will keep their eyes open for Rails-ish web frameworks of the likes of Helma.

Hey Steve, you can find it here: http://helma.org/ :-)

So, I think this is great news for Rhino, and as a result great news for the Helma project.

>>> Release Candidate 3 of Helma 1.6.0