cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: Lets Not Go Big Game Hunting!
Date Thu, 24 Jun 2004 18:29:02 GMT
Ugo Cei dijo:

> Now, there's one thing that actually bugs me. It's the fact that I am
> using very little of Cocoon's traditional components and traditional way
> of doing things. No XSP, no Avalon components, our sitemaps are reduced
> to lots of <map:call>s and a few pipelins for rendering views (basically
> just a fixed template), the only kind of generator we use is JXTG. I'm
> starting to wonder whether Cocoon's dual nature, an XML-based publishing
> engine living together with a rapidly-evolving Web application platform,
> isn't dragging us down. And I'm also starting to wonder whether this
> duality will cause some friction in the community, in the near future.

Same feelings as you, with a little exception: we use OJB instead of
Hibernate. But for the big picture it does not matter. ;-)

I think it is natural to use a subset of Cocoon for every application. We
use just some blocks. We build and squeleton that is improved if needed
and is reused on each new application.

I don't believe that the dual nature of Cocoon will be against us. I think
it is good to know that if we need other stuff we can have it at hand.
What if we need to read some data from an HTML page? There is the HTML

The problem I see is that you are talking more about clasical DB oriented
webapp, I think the natural evolution of this kind of applications will
set the higher levels than we know today and will force us to use other
technologies covered in other cocoon blocks.

As a sample, take a CMS. It can saw as a DB webapp? I think yes, but it
needs diferents approaches than classical DB applications as we know

Best Regards,

Antonio Gallardo.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message