cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Public/Private classification (was Re: javadocs navigation)
Date Thu, 13 Oct 2005 17:01:26 GMT
Daniel Fagerstrom wrote:
> Upayavira wrote:
>> So, I have created a wiki page:
>> 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.


View raw message