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.
I don't think its quite as bad as you make out. The intended public interface of Ovidiu's design is really quite simple and elegant. The problem is that a lot of the apparent "interfaces" in JSCocoon.java are really implementation details. Here is a pseudo-idl depiction of the "real" public interface (Ovidiu, correct me if I'm wrong):
interface Cocoon {
readonly attribute request;
void createSession();
void removeSession();
void sendPageAndWait(in string uri, in Object bean,
in int timeToLive);void sendPage(in string uri, in Object bean, in int timeToLive);
boolean process(in string uri, in Object object,
in OutputStream stream);}
Note that sendPage*() are actually global functions (but I think they can and should be operations of Cocoon like "process()").
With the exception of the Input/Output module stuff, "load()" (which I can now confirm doesn't actually work), XMLForm, and the Database stuff (and I think we can all agree these should be removed or moved elsewhere), the other stuff is just there to support the implementation of sendPage*().
Regards, Chris
