[RACOON] Cocoon refactoring (was many other things)

[Nicola Ken Barozzi <ni...@apache.org>]

Vadim Gritsenko wrote:
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>>Vadim Gritsenko wrote:
>>
>>>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>>
>>>
>>><snip/>
>>>
>>>>Now, has anyone easily used Cocoon out of a Servlet environment?
>>>
>>>
>>>Ant to build docs - yes. Offline generation is another one used by
>>
> some
> 
>>>people.
>>
>>Ha. *easily* I said.
>>Peter Donald ov Avalon is not the last programmer on earth, yet he
>>doesn't know yet that with Cocoon CLI you can supply a list of URLs to
>>preocess and *not* crawl. I'm 100% sure it's not his fault.
> 
> Because (IIRC) there is no docs to it. And refactoring, remodularizing,
> forresting, etc will not help this situation - as Andrew pointed out.
> And I cannot not to agree with him.

I never said that documentation has not to be there.
The point is that if someone needs to read a book just to get started 
proficiently, I say we're off track.

>>And how about embedding Cocoon in other apps?

:-?

>>>>We need a _CocoonBean_, that becomes the core entry point.
>>>>You give it a sitemap, input, and it processes the output. Simple as
>>>
>>>that.
>>>
>>>What's wrong with Cocoon.java? It *is* the entry point. If you don't
>>>like something in it - let's fix it, why start another /bean/?
>>
>>Simply because Cocoon.java is not an easy entry point.
>>Look how Main.java calls it, and you will understand how it's not
>>user-friendly.
> 
> 
> 
> Cocoon c = new Cocoon();
> c.setLogger(log);
> c.contextualize(appContext);
> c.setLogKitManager(logKitManager);
> c.initialize();
> FileSavingEnvironment env =
>   new FileSavingEnvironment(deparameterizedURI,
>                         context,
>                         attributes,
>                         parameters,
>                         links,
>                         stream,
>                         log);
> c.process(env);
> c.dispose();
> 
> Not one line, yes, but not impossible, too... The complexity here is
> that Cocoon is a Component.

And you didn't write how you created log, appContext, logKitManager, etc.
This makes it much longer.

>>We can fix that instead of making a bean, this is just an
>> implementation
> 
>>issue. I just thoght that creating a bean would break less stuff that
>>now is depending on the "old" Cocoon.java.
> 
> 
> Ok, +1 for CocoonBean. Let's keep Cocoon.java as is.

Ok, but this is just the tip of the refactoring.

Ok :-/ , let me write it here first.

Take Cocoon src/java/org/apache/cocoon/.

Remove all the implementation in
  acting
  generation
  matching
  reading
  selection
  serialization

and make a src/components/componentname/org/apache/cocoon/* hierarchy 
where you put them.
Make a single componentname called common for the common components that 
do not depend on other jars.
Move also the webapps packages

Now we have in the src/java/org/apache/cocoon/*
  acting/Action.java
  generation/Generator.java
  matching/Matcher.java
  reading/Reder.java
  selection/Selector.java
  serialization/Serializer.java

Which is plain stupid, so we can simply make them in a package called 
components.

Then we need to show the layers in Cocoon as packages.

so we will have
  components (we have already moved the interfaces)
  pipelines (we should move here the pipelines)
  sitemaps

Then the util package, the existence of which always makes me uneasy, in 
every project I see.
I propose to move this to Jakarta Commons, where it already has been 
voted positively to make XML.Apache members possible to work in the sandbox.

Then we have the current /components, that need to be split into real 
Cocoon-Avalon components or ones used by Sitemap Components.
The latter should go along with the 
src/components/componentname/org/apache/cocoon/components/*
naming scheme, or similar.
The Cocoon system components into services, and switch from Composable 
to Serviceable.

Finally we need to move all frontends to a cocoon/frontends or similar, 
that will have Main.java, renamed to Commandline.java, CocoonTask.java, 
CocoonServlet.java, etc (so remove Cocoon/servlet in the Process).

finally it will be something like:
  components (only interfaces)
  pipelines (interfaces+an impl package)
  sitemap (interfaces+an impl package)
  environment (interfaces+ impl package)
  frontends (only implementations and also CocoonBean)
  Cocoon.java

i18n and caching goes into the serviceable stuff.

Then we need to formalize the Source stuff, and separate cleanly the 
localiation stage from the Generation stage.
And then see how to interoperate with Morphos, or simply inglobate it.

This would be the first run, then there are other things to do like 
switch to Fortress/Merlin, clean the lifecycle interface and expose less 
components and more services.
Oh, and then make blocks ;-)

This is what is in my head, see if it makes sense.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org