cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Date Mon, 05 Aug 2002 14:05:47 GMT
> 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.

 
> 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.


> 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.

Vadim


> --
> 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


Mime
View raw message