Reinhard Poetz wrote:

Boy, this is getting frustrating.

I don't give a proverbial f*&k on how we do it the fact is that there are many levels of "public API" and we are not acknoledging that, nowhere something like this can be found.

In the past, we wanted FOM to be the only interface between flowscript and the rest of the system but given how many services are embedded in components and how many things were never added to FOM but just expected to be discovered out of getComponent(), which means that you need to know the entire cocoon internals to be able to write a simple flowscript, which is totally ridiculous.

You want principles? here they are:

1) script-oriented people, those who don't know java and don't care, those looking for RAD, those coming from the client or from the XML world, should have a reduced API which includes FOM + useful components + environment API and no cocoon internals.

2) for power users, willing to extend cocoon, the cocoon internal APIs (pipelines, caching, input modules, etc..)

3) for cocoon devepers, everything but at least packaged by block.

This is what I want.

I don't care if we do it by hand or we do it by javadoc or by other means.

I don't care if we use wikis or post-its to find out which interface goes in which category(s), or if we use tags or even if we use embedded RDF in the javadoc comments for it.

All I want is to help our users stick around... because honestly, I find myself in the very uncomfortable position of suggesting people *NOT*TO* use cocoon, because is such a horrible climb to get to that comfortable plateau of productivity and this is honestly not acceptable today.