On 5/3/03 7:29, "Christopher Oliver" <[EMAIL PROTECTED]> wrote:
> Pier Fumagalli wrote:
>>
>> 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.
I know... But where can I read it? Where will our users be able to see that
all those function they rely on are actually "implementation details" and
that they shouldn't even touch them because we can remove them in the next
release? (if the language doesn't allow you to specify that something is
"private", it doesn't mean that you should be allowed to use it anyway).
> 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);
>
> }
It's would be a very nice interface, but it is NOT what we have today...
Apart from the sendPage*() stuff which are not there, we have _A_LOT_ of
other attributes and functions accessible from that object... And I mean, A
LOT. You listed one attribute and 5 functions, I count 8 attributes and 10
functions...
As nowhere it's said that "you shouldn't be allowed to use the rest", I
started USING those in my own scripts... Now you're telling me that I might
have to rewrite them because in the next version "they could not be there,
renamed or stuff"???
> Note that sendPage*() are actually global functions (but I think they
> can and should be operations of Cocoon like "process()").
What you are referring as "global" are actually instance functions of the
current script... As you can (in theory) be able to call them with
"this.sendPageAnd*(...)"
> 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*().
Looking at the code I have to disagree: the only things in JSCocoon which
handle the basic functionalities we use are the forwardTo and process
functions and environment attribute.
Actions and input/output modules are handled through instance functions in
the current script, while XForm is no more and no less than an inner class
of the current script instance (???whaaaaaat???)...
And in script.js there's also an "extra" method defined for the Database
class (which ends up being ScriptableConnection.java), function(selector):
basically, ScriptableConnection has _one_ more method if you use it together
with a flow script than it would if it was used by itself (ok, we don't use
JavaScript anywhere else, _BUT_)...
You were right, it's not as bad as I make out, it looks _worse_... But thank
god those are all implementation details :-) :-) :-)
Pier (JavaScript != PERL)
