[RANT] The Flow...

[Pier Fumagalli <pi...@betaversion.org>]

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...

Re: [RANT] The Flow...

[Pier Fumagalli <pi...@betaversion.org>]

On 5/3/03 22:47, "Christopher Oliver" <re...@verizon.net> wrote:

> OK. Following Pier's approach, I've also tried to start documenting the
> "Cocoon Flow Object Model" everything that is currently under
> flow/javascript in CVS - whether I think it should be there or not -
> using IDL and generated JavaDocs using openorb's idldoc.
> 
> The idl is here:
> http://www.primaryinterface.com/cocoon/idl
> The javadocs here:
> http://www.primaryinterface.com/cocoon
> 
> Let's discuss these interfaces and change them to what we want.

FUCK YEAH! :-) (whops sorry) Chris, would you mind placing those IDL files
in CVS? src/idl would be the best, IMO...

Now off to find that IDLDOC thing...

    Pier

Re: [RANT] The Flow...

[Christopher Oliver <re...@verizon.net>]

OK. Following Pier's approach, I've also tried to start documenting the 
"Cocoon Flow Object Model" everything that is currently under 
flow/javascript in CVS - whether I think it should be there or not - 
using IDL and generated JavaDocs using openorb's idldoc.

The idl is here:
http://www.primaryinterface.com/cocoon/idl
The javadocs here:
http://www.primaryinterface.com/cocoon

Let's discuss these interfaces and change them to what we want.

Regards,

Chris

Re: [RANT] The Flow...

[Geoff Howard <co...@leverageweb.com>]

At 08:31 AM 3/5/2003, you wrote:
>On 5/3/03 7:29, "Christopher Oliver" <re...@verizon.net> wrote:
>
> > Pier Fumagalli wrote:
> >>

<snip/>

> > 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).

Excuse my ignorance of the flow implementation to date, but wouldn't it 
make more sense to only expose methods to javascript that are meant to be 
public?  If an implementation issue is meant to be private/package 
protected etc. why is it not handled in java as such and not exposed at all 
to the flow scripting?

Geoff 

Re: [RANT] The Flow...

[Per-Olof Norén <pe...@alma.nu>]

Christopher Oliver 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. 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);
>
> }


Ok,  just to put things in pespective:
Numerous threads have disussed  "integration" with the flow layer. There 
have been different approaches to the problem and theese solutions have 
evolved with the word "integration" in the back of peoples minds. This 
may have resulted in a not so very constistent OM.  
As I agree with Stefano and now Pier, about massaging an interface/OM 
that lasts, I think we should sum up all various scenarios that can 
occur using flow.
examples might be:
1. Interaction with authentication framework
    How to get the hands on attributes specified and should they be
2. Interaction with  business logic:

As I promoted in the flow O/R thread earlier, we are using the flow + 
OJB. To do this we have an Avalon Component wrapping the OJB 
PersistenceBroker (the low-level endpoint OJB used to retreive the java 
objects from db). From inside the flowscript the business data to be 
sent to the view (in our case an xsp) is loaded by asking COCOON´s 
component manager for our PersistenceManager (our wrapper uses a similar 
name to the OJB counterpart: PersistenceBroker).
This is obviously *not* the optimum way of doing this, one should not 
need to manipulate cocoon´s internal roles file to be able to locate and 
use the business-logic.

Mats Norén (my brother, btw :)) raised the question about the need for 
an alternative, possible block specific componentManager , a 
BusinessComponentManager (BCM)  that one use to call  the business-logic 
implemented in java and forward the resulting bean/beans to sendPage.

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104254063324113&w=2

So I´d think this intended interface is a little edgeless in terms of 
actually retrieving beans/data to send.
I propose the inclusion of a separate ComponentManager that flow can 
use. This ComponentManager should be set up/managed by the application 
builder.
The interface /OM should allow access to this manager for retreival of 
 business components and/or persistence mechanisms.


Regards,
Per-Olof Norén
Curalia AB

Re: [RANT] The Flow...

[Christopher Oliver <re...@verizon.net>]

Pier Fumagalli wrote:
> On 5/3/03 14:52, "Christopher Oliver" <re...@verizon.net> wrote:
> 
> 
>>It should be documented that the rest are "private" and as a normal user
>>of the flow layer I think you probably shouldn't be using them.
> 
> 
> So, can I please ask to everyone not to hack around the flow O/M before that
> "documentation" is written and carved in stone?
> 

If by everyone, you mean me, then no problem.

> 
>>What did you use, and what did you use it for?
> 
> 
> CompnentManager, to look up a couple of things I needed. Not _that_ bad from
> an implementation perspective, but _very_ bad from a design POV.
> 
>     Pier

Would you mind explaining why you needed it?

Regards,

Chris

Re: [RANT] The Flow...

[Pier Fumagalli <pi...@betaversion.org>]

On 5/3/03 14:52, "Christopher Oliver" <re...@verizon.net> wrote:

> It should be documented that the rest are "private" and as a normal user
> of the flow layer I think you probably shouldn't be using them.

So, can I please ask to everyone not to hack around the flow O/M before that
"documentation" is written and carved in stone?

> What did you use, and what did you use it for?

CompnentManager, to look up a couple of things I needed. Not _that_ bad from
an implementation perspective, but _very_ bad from a design POV.

    Pier

Re: [RANT] The Flow...

[Christopher Oliver <re...@verizon.net>]

Pier Fumagalli wrote:
> On 5/3/03 7:29, "Christopher Oliver" <re...@verizon.net> wrote:
> 
> 
>>Pier Fumagalli wrote:
>>
> 
> 
> 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).

Clearly, there needs to be much better documentation. And I do agree 
there can be a lot of cleanup in the implementation. And I think 
continued discussion can help improve the design. All of those things 
need to happen and hopefully will.

> 
> 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"???
> 

It should be documented that the rest are "private" and as a normal user 
of the flow layer I think you probably shouldn't be using them. What did 
you use, and what did you use it for?


Regards,

Chris

Re: [RANT] The Flow...

[Pier Fumagalli <pi...@betaversion.org>]

On 5/3/03 7:29, "Christopher Oliver" <re...@verizon.net> 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)

Re: [RANT] The Flow...

[Christopher Oliver <re...@verizon.net>]

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. 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

Re: [RANT] The Flow...

[Pier Fumagalli <pi...@betaversion.org>]

On 5/3/03 4:41, "Pier Fumagalli" <pi...@betaversion.org> wrote:

> Check out the "flowspec/Cocoon.xml" file, [...] load it up in Mozilla [...]

For once, it works _ALSO_ in MSIE/6.0sp1 on Win2K... Incredible...

    Pier (love replying to self)