cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: FYI: Using Java to define Cocoon Flow
Date Tue, 13 May 2003 18:16:08 GMT
on 5/13/03 7:21 AM Geoff Howard wrote:

> At 01:45 AM 5/13/2003, Bertrand wrote:
>>Le Mardi, 13 mai 2003, à 01:15 Europe/Zurich, Stefano Mazzocchi a écrit :
>>>....I'll tell you what: if I had a java implementation of flow in cocoon
>>>*today*, I would still use the javascript version for these reasons:....
>><snip valid reasons/>
>>I agree that for short flowscripts, javascript is very well suited, 
>>concise etc.
>>(and aren't all flowscripts supposed to be short?)
> I wonder - won't it prove useful having the benefit of inheritance and 
> import in
> flow?? (which java would get you) You could then wind up with some common code
> that can be reused in whole or in part for different but similar 
> tasks.  This has
> always been a question in the back of my mind about javascript - it seems 
> like it
> will force more copy-paste coding than would be healthy when working on a 
> larger
> system.

Javascript is not as powerful as an object-oriented language as java,
that's for sure, but stating it doesn't allow inheritance is wrong.

The flowscript allows imports to happen thru a call to cocoon.load(file)
where file is the name of the script to load into the execution context.

[Chris, correct me if I'm mistaken]

javascript allows you to create objects and also allows you to
manipulate objects.

how? well, the "prototype" property of any object give you access to the
underlying implementation of that object. It's more or less like java
reflection, but it's read/write and javascript has "function" as a
native object, unlike java.

So, take a look at this:



  function main() {
	var o = new MyObject();



  MyObject.prototype = new Object();
  MyObject.prototype.constructor = Object;
  MyObject.superclass = MyObject.prototype;

  function Myobject()
    	// construct the object


  function Object() {
	// construct the object

  // a bunch of functions

As you see, it's not as transparent as Java, that's for sure, but it is
indeed possible and very friendly at the end. This is the way
cross-browser compatibility libraries are written or how you can patch,
say, mozilla, if their DOM implementation is broken.

[there is a cool library for DOM2 ranges that does a unit test on the
dom and patches it with a javascript-only method if the original DOM
method is broken. Very cool!]

For a more detailed example see

in fact, javascript would be even better for AOP paradigms than java
because of functions as first-class citizens in javascript and
.prototype which is much easier to use (IMHO) than java Proxies.

Note that I'm not advocating that use of inheritance for the flow, I
don't think you'll ever need it, but .prototype is a very handy thing,
IMO, the most important javascript feature.

Java and javascript share the syntax but they are completely different


View raw message