cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Less is more... or less? (was Re: v2 forms flowscript example)
Date Mon, 22 Mar 2004 10:34:22 GMT
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. We had IDL, which was abandonned 
because it wasn't maintained. I won't blame anyone for this as I'm the 
first one to dislike writing docs, but I do write javadoc in the code. 
Javadoc *is* the reference for our APIs, and where users dig to find 
what's available, even those who don't write a single line of Java but 
use only flowscript. Imagine how frustrating it is to see some feature 
you need available on the Java object, but not on the JS one...

So less is less when you have more on the *same* object accessed 
directly in Java.



Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message