cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: Public/Private classification (was Re: javadocs navigation)
Date Fri, 14 Oct 2005 13:01:32 GMT
Stefano Mazzocchi wrote:
> Daniel Fagerstrom wrote:
> 
>> Daniel Fagerstrom wrote:
>>
>> To illustrate what I meant I tried to follow the dependencies for the 
>> sitemap component interfaces.
>>
>>> Cocoon API
>>> ==========
>>
>>> So what is the Cocoon API? All interfaces used in 
>>> cocoon-core-sitemap.xconf are part of the Cocoon API: Generator, 
>>> Transformer, Serializer, Reader, Matcher, Selector, Action, 
>>> ProcessingPipeline. Then the interfaces refered to in the Cocoon API 
>>> must be part of the API as well by transitive closure. So here we get 
>>> various exceptions, SitemapModelComponent, XMLPipe, XMLProducer and 
>>> much more. The ObjectModelHelper with dependencies is also part of 
>>> the API.
>>
>> Starting with:
>>
>> org.apache.cocoon.acting.Action
>> org.apache.cocoon.generation.Generator
>> org.apache.cocoon.matching.Matcher
>> org.apache.cocoon.reading.Reader
>> org.apache.cocoon.selection.Selector
>> org.apache.cocoon.serialization.Serializer
>> org.apache.cocoon.transformation.Transformer
>>
>> (I removed the ProcessingPipeline as it dependencies seem to explode 
>> to all kinds of internal classes, we need to polish that interface if 
>> it should be considered public)
>>
>> These interfaces depends on:
>>
>> org.apache.avalon.framework.parameters.Parameters
>> org.apache.cocoon.ProcessingException
>> org.apache.cocoon.environment.Redirector
>> org.apache.cocoon.environment.SourceResolver
>> org.apache.cocoon.sitemap.SitemapModelComponent
>> org.apache.cocoon.sitemap.SitemapOutputComponent
>> org.apache.cocoon.sitemap.PatternException
>> org.apache.cocoon.xml.XMLConsumer
>> org.apache.cocoon.xml.XMLPipe
>> org.apache.cocoon.xml.XMLProducer
>>
>> which depends on (skipping the avalon dependencies)
>>
>> org.apache.avalon.framework.CascadingException
>> org.apache.cocoon.util.location.LocatedException
>> (org.apache.cocoon.util.location.LocatedRuntimeException)
>> org.apache.cocoon.util.location.Location
>> org.apache.cocoon.util.location.MultiLocatable
>>
>> and again
>>
>> org.apache.cocoon.util.location.Locatable
>> org.apache.cocoon.util.location.LocatableException
>> org.apache.cocoon.util.location.LocationImpl
>> org.apache.cocoon.util.location.LocationUtils
>> org.apache.commons.lang.exception.NestableException
>> org.apache.commons.lang.exception.ExceptionUtils
>>
>> ===
>>
>> The object model helper must also be considered to be part of the 
>> Cocoon API, there we get the dependencies:
>>
>> org.apache.cocoon.environment.ObjectModelHelper
>>
>> -->
>>
>> org.apache.cocoon.environment.Context
>> org.apache.cocoon.environment.Request
>> org.apache.cocoon.environment.Response
>>
>> -->
>>
>> org.apache.cocoon.environment.Cookie
>> org.apache.cocoon.environment.Session
>>
>> ===
>>
>> This should be a complete list of the public sitemap component API (I 
>> did the dependency analysis semi automatically with 
>> http://depfind.sourceforge.net/, so I could have done some mistakes).

It's not complete - at least InputModule interface is missing, may be something 
else. But it is a good start.


>> A similar list for the public component API, starting from 
>> cocoon-core.xconf would also be a good idea. But I would need a better 
>> tool than depfind for that excercise, any suggestions?

I am not sure everything declared in the cocoon.xconf is public API, although 
most of the stuff is, such as xml parser, xslt processor, runnable manager, etc.


>> I'm not suggesting that we can find out the Cocoon API automatically. 
>> But given that we want a particular set of interfaces in the public 
>> API and JavaDoc, I think it would be rather strange if we didn't made 
>> all the o.a.c interfaces and classes that these interfaces depends on 
>> also part of the public API.
> 
> 
> Daniel,
> 
> let me repeat: I don't care about precision and elegance and 
> completeness, I care about usability.
> 
> I am thinking at flow users that want to use java components to do their 
> stuff. They should *NOT* care about org.apache.cocoon.xml.XMLPipe.

Users that write *own* components *do* care about XMLPipe.

Vadim

Mime
View raw message