Daniel Fagerstrom wrote:

Here's my principle: since I write all my business logic in flow, I want to know which ones are the things that I can expect to call from flow.

Documenting FOM is one thing, but then we have a bunch of other things (like SourceUtil and excalibur resolver etc) that I use all the time.

So, my rationale is not to document XMLPipe (since I'll never use it or implement it in flow) but to have an idea, from the cocoon user point of view, of where are the hooks.

So, there are 4 levels:

1) FOM (the javascript objects available to flow) 2) the static java utils + avalon components 3) the cocoon interfaces 4) the cocoon classes

we document #1 (badly, if you ask me, it's a pain to find) and the rest is one huge bundled javadoc and our class classification by package does *NOT* induce itself to the classification above (maybe #3 and #4, given that we use impl to indicate what implements an interface, and we use .components even if not all of those are meant to be used in flow)

If we want to appeal to the users, we need to tell them loud and clear what are the hooks they can use. Otherwise, it feels like flying without a net.

Some people here want to move to javaflow to have eclipse do the work for them, I think we have to do something anyway.