On 5/3/03 15:53, "Hunsberger, Peter" <[EMAIL PROTECTED]> wrote:

> Pier Fumagalli <[EMAIL PROTECTED]> wrote:
> 
>> <[EMAIL PROTECTED]> wrote:
>> 
>>> Pier Fumagalli <[EMAIL PROTECTED]> wrote:
>>> 
>>> <snip on how Pier arrived at the following:/>
>>> 
>>>> 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.
>>>> 
>>> 
>>> Yes please!  But while you are at it, don't you really want
>> to define 
>>> a complete Cocoon object model and not just one for flow (I think
>>> that's maybe what you're already doing?)?
>> 
>> I don't have 3 months to document that _WHOLE_ thing! :-)
> 
> Fair enough, but how about a high level sketch of where the other parts fit
> in?  Something like:
> 
>        complete model
>             |
>      +------+----------+
>      |      |          |
>    flow  environment  whatever
> 
> Where only "flow" is completely documented at the moment? (And yes, I
> realize the hierarchy is probably more complicated than that, that's why I
> need some documentation...)
> 
> I fear that if you only document "flow" people will add things to flow
> because they don't know where else to put them...

Most of the rest of the stuff is accessible from the JavaDOC. It's fairly
easy to see what does what from that kind of documentation. Ok, it might be
better to have a nice paper on where the different bits come into play
(what's an environment, when it's created, how does the sitemap processes
requests and how its components deal with it, and so on)... Volunteering
yourself? :-)

The flow requires a different "API" documentation, much like the W3C dom
specification and IDL definitions, because it has to deal with several
languages, it's partly defined in Java and partly in the language of your
choice (JavaScript for now, Python and others as well in the future?), and
it deals with an object model "instantiated" in several points of our
codebase...

    Pier



Reply via email to