Daniel Fagerstrom wrote:
Upayavira wrote:
So, I have created a wiki page:
http://wiki.apache.org/cocoon/PublicAPIClasses
Please go there and mark classes public/private as necessary. As it
says at the top of that page, if you disagree with someone, change it
to "dispute" or D for short. Then it becomes an opportunity for some
healthy argument!
Wow! that's a lot of classes. While I aplaud the initiative, 673 classes
are huge amount to classify. I would suggest that we start discussing
principles first a bit.
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.
--
Stefano.
