cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <un...@hippo.nl>
Subject Re: [Vote] Marking internal classes
Date Mon, 19 Jul 2004 11:52:06 GMT
Sylvain Wallez wrote:

> Unico Hommes wrote:
>
>> Reinhard Poetz wrote:
>
>
>
> <snip/>
>
>>> I also propose to separate the cocoon.jar into two parts: One that 
>>> contains all interfaces that can be implemented and all classes that 
>>> can be used or extended and a second jar that contains the rest 
>>> which is only used internally. After migrating to Suversion this can 
>>> be done without breaking the history because this will also require 
>>> some file moving. IMO this step is necessary to separate our blocks 
>>> from Cocoon core, isn't it?
>>
>>
>
> Good idea, but IMO this complements marking the classes, as if you 
> load the full Cocoon in an Eclipse project, completion will show all 
> classes. A notice at the beginning of the javadoc helps in noticing 
> that you use something that's forbidden.
>
>> I like this too. There could be more than two parts though. There is 
>> the API part that contains interfaces used to embed cocoon into a 
>> certain environment. The SPI interfaces developers implement to 
>> extend the functionality of Cocoon. The different API implementations 
>> that we have (CLI, Servlet). And finally the core components.
>
>
>
> Can you elaborate on the difference between API and SPI?
>

This is the way they separate their code into modules at Avalon. I like 
it because it clearly marks the different functions separate parts of 
the code play in an application. Interfaces that function as SPI's are 
for instance the different sitemap component interfaces: Transformer, 
ProcessingPipeline, Reader, Matcher, etc. An example of an API level 
interface is for instance Processor and the different environment 
related interfaces: Request, Context, Environment, etc.

--
Unico

Mime
View raw message