 |  |  |  | Previous Cocoon releases said that this product was to consider a
proof of concept rather than a working solution. I can't find that sentence
anymore. What happened? |  |  |  |  |
We believe that Cocoon has entered the final stage of its evolution but
as it stands today, it is ready to be used for a production environment.
Careful, we don't say it's perfect or bug-free, this is impossible to say,
but at least, we think this technology is good enough for you to try it out
against other solutions for web publishing.
Warning: this doesn't mean that Cocoon evolution came to an end, not at all,
but that we believe it's mature enough to be deployed in a working environment
with no particular problems.
Note, however, that this software comes "as is" so you should always be
aware of the risks as for any other open source software, but I think that
if you read this, you already know what we mean :)
|
 |  |  |  | Why do I keep getting FileNotFoundException under Tomcat 3.0? |  |  |  |  |
 |  |  |  | How come Cocoon doesn't work on Tomcat 3.0? |  |  |  |  |
 |  |  |  |
I think that using Processing Instructions to "chain"
document layers somehow violates the context separation since I would like
to be able to place style sensible information in sessions or request
parameters. What do you think about this?
|  |  |  |  |
You are right, PI reaction breaks the context separation and it's, at the
very end, the wrong approach. To follow a complete "model, view,
controller" design pattern, one should be able to associate a different
processing chain for each requested URI and for every possible request state
(with request parameters, session parameters and environment parameters).
The proposed solution (as you read in the ) is to have a site map where site
managers decide what processing chain to apply to each possible request.
This somehow follows the mod_rewrite model in the Apache Web Server, but
rather than URL rewriting, the site map allows site designers to control the
behavior of their documents in one place without having to modify every
single reactive PI in each source file.
So, you've been warned: the PIs will go away, current functionality will
remain but the processing management will be abstracted one layer up.
|
(Cocoon's creator Stefano Mazzocchi answers): It's a pretty stupid reason and a funny
story: I spent my 1998 Xmas vacation with my girlfriend up on the Alps at her cottage. One
night I couldn't sleep, I went to watch some TV and finishing reading the XSL
documentation I brought with me. Being a science fiction afficionado, I found out
that Ron Howard's movie Cocoon was on and I started watching it. The idea of the XSL
rendering servlet stoke me like the alien "cocoons" in the pool stroke those old men in the
movie and, while watching, I started paper-coding it right away. After a while the movie
was over and the publishing framework designed. The name "Cocoon" seemed right
for the thing, meaning to be a way to bring new life to old ideas as well as to create cocoons
for such new ideas to become beautiful butterflies. :-)
|
|