Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Why is there a need to have a different API for widgets when used from JS than when used from Java? IMO, this is arbitrarily limiting the features available in flowscript.
But isn't this our design approach? If I remember correctly our FOM discussions, "less is more", right?
Well, time for a bit of rant on this.
I'm personally not that happy with "less is more" as it was applied to FOM. Although I agree that bloated APIs should be avoided, restricting the Cocoon core APIs (the environment) in some specific area of Cocoon (flowscript) seems to me an arbitrary constraint.
Yes, not that many people have asked for more of the Java environment APIs to be visible. But why so? Simply because people (and I talk about what I've seen in real customer projects) often end up writing a simple Java class that allow them to access the real Java object and therefore use the *full* environment API in their flowscripts. This leads to clumsy constructs that overcomplexify the flow scripts.
That's why I don't like the JS-specific APIs, except those that allow shorter notations through properties.
Furthemore, this makes learning more difficult, as people have to learn *two* APIs to know what is (or is not) available in flowscript. And as we have no explicit auto-generated documentation for the flowscript APIs, this is a lot of trial and error.
Well, the JS Flowscript API is documented: http://cocoon.apache.org/2.1/userdocs/flow/api.html.
Although I agree with you that there should not be unnecessary limitations in the JS API as compared to Java, nevertheless I think it's unavoidable that there will be some differences. This seems to be the case more generally with any Java scripting language. For example, JS String and java.lang.String do not have the same API:
var length = "Hello".length;
var length = new java.lang.String("Hello").length();Compare also JS DOM versus Java DOM. I really don't see how such mismatches can be avoided completely. You'll run into the same thing with Jython, Groovy, etc. The net result of this is that, yes, the user will have to learn two API's (although similar).
Nevertheless, at least in my experience the combination of a scripting language and a system programming language has always been a winning combination. At my previous company, we developed tools for the abstract syntax language ASN.1. We provided a mapping to C++ classes, but we also implemented an ASN.1 API for the TCL scripting language. In constrast to JS/Java, TCL syntax is drastically different from C++. So the API's were not identical but however provided equivalent functionality in their own way. With the close similarity between JS and Java syntax it's tempting to try to make the API's identical, but there are important features only in JS (first class functions, closures, etc) that can and should be exploited.
My opinion is that any Cocoon JS API's should be developed to provide the best possible JS programming environment for the user. If this results in a different API than that provided in Java, so be it (although I think we should strive to make them the same where possible).
Chris
