I've been spending this weekend a little bit far away from Cocoon, actually
doing some really interesting stuff involving JavaScript, DOM and browsers
all on the client side...
What I came to realize, is that, although JavaScript _looks_ messy (and
browsers implementations, Mozilla included, tend to make it that way, not
giving a clear impression of design), it actually is a _very_ clean
language...
To go back on my trail, I started hacking around between Mozilla and IE,
disconforted by the lack of documentation, I downloaded and read the entire
JavaScript, DOM Level 2 and part of the DOM Level 3 specifications.
Especially from reading the DOM spec, I noticed that the defined object
model (the one that should be at the core of every browser) is actually
_VERY_WELL_ defined, and completely abstract from the programming language
used: you can access the DOM in a browser from - let's say - C++, Java, or
JavaScript, and regardless of the actual language, you should grasp quite
quickly the little tiny differences between the different "bindings" of the
same core objects.
DOM, especially, goes one step further, defining its structure in IDL, the
"Corba definition language" (as us illiterate call it), and defines
"bindings" from its IDL definitions to Java and JavaScript.
I come back to beloved Cocoon and I see a quite lengthy thread about JDBC
and FLOW (stuff that I do already for my employer) and see that Chris added
all this support in the "cocoon" object... My forged-by-browsers-JavaScript
mind accepts it, but that little Stefano in my brain (he planted a some kind
of bug between the three neurons 8 years ago) tells me that, nah, it doesn't
really make a lot of sense... BUT WHY? Am I able to _explain_ myself what I
_feel_ wrong in the flow? Unfortunately not...
Until tonight, when I realized that the frustration towards Chris addition
was the same exact feeling I experienced when looking at client-side
browser-based JavaScript of Netscape 4.x. It simply lacks of _DESIGN_...
Back to the drawing board, my fellow IDL editor at hands, and I start doing
one weird thing: converting the flow object model into IDL, as the current
JavaDOC output of JSCocoon and friends doesn't look "easy and nice",
preventing me to visually see if it's an implementation problem (all those
jsGet_whatever, jsSet_Something and jsFunction_Yadayada are making me go
nuts) or a more important and radical _design_ problem.
Let me tell you one thing, after I wrote a couple of IDL interfaces, it
started to come out... It looks like there is no whatsoever OO-design behind
the flow object model, and that's the same feeling you get when you take
MSIE and try to make sense of its Jscript stuff.
IDL, though, is _NOT_ an easy to look-at language, and there ain't no
JavaDOC. As we don't _NEED_ IDL for the flow, I'm starting to rewrite these
objects in a XML-based-kind-of-javadoc-lookalike format...
Basically, once you see in the big picture what you can _access_ from the
flow, as you would do from a browser to access its document DOM, you'll see
what I mean. IT DOESN'T MAKE SENSE. It's a collection of hacks....
The "first" interface ("Cocoon") is ready, it's written, and looking at it
in my Mozilla it doesn't look _that_ nice... Output and input modules? Why
"load" is there if we have an "interpreter" (which is supposed to deal with
this sort of stuff? And how "displayAllContinuation" works? I _don't_ like
it.
What I would love to have, before even touching the flow _implementation_,
is a consistent language-unaware definition of the object model that flow
scripts will live into, define bindings from this object model to
JavaScript, so that we all know what we are _supposed_ to implement, why,
where and when.
Check out the "flowspec/Cocoon.xml" file, it's the current representation of
JSCocoon seen from Javascript, load it up in Mozilla, look the XML file
itself (you're all much better in reading XML than I am), change it, add new
object definitions.
I believe that before we can call a release, we need to have a _proper_
object model for flow scripts, well defined, well architected. The other
only outcome I see otherwise is the same _HUGE_ mistake that browsers did
when they started to make pages scriptable...
And we don't want to do that very same mistake, right? :-)
Pier
BTW, despite this "harshness" the flow is just mind-blowing. There isn't
anything even close to it available now... As I see the potentialities of
if, and cherish the concepts in my private little shrine at home, I believe
it's even more important _NOW_ to do it right... And, IMO, we can...
