cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Lamb <>
Subject RE: [RT] i18n in Cocoon and language independent semantic context s
Date Mon, 12 Jun 2000 15:04:33 GMT
> Paul Lamb wrote:
> > 
> > BTW, Stephano, what's your native language? 
> Oh, gee, this is a lost cause... my name is Stefano, pronounced as
> "Stéh-fan-o" NOT "Ste-phà-no", grrrr

Looks like yesterday wasn't a good day for spelling your name, as I
destroyed your first name and someone else the last. I do apologize, I have
a good friend here who's name is Stephan, who is often close enough nearby
to physically knock me up-side the head when I get it wrong.

> > 
> > Or, "How can we design both the sitemap and the engine to expect
> > evolutionary changes? What about revolutionary ones?"
> Ouch, touched a nerve here.

Didn't mean to, you've been asking these types of questions a lot lately,
and I think it's good thing. I've been in the process of moving two sites to
their third generation of implementation and I really remember thinking
about this during the last set of changes. But now it seems that I either
really got it right or I really got it wrong, not much in between.

> What's the best way to integrate it? Apache should become a native
> version of Cocoon? Should Tomcat? Should Catalina?
> I have no idea, but I'm doing something.
> I do plan to use Catalina-specific hooks when it becomes mainstream.
> (Catalina is the codename for what many believe it will be Tomcat 4.0)
> This would allow us to use sitemap.xml "instead" of web.xml for
> cocoon-based applications.
> > The first thought that comes to 
> mind here, is
> > something like a valve pattern, like Craig's done with catalina.
> Exactly.

This brings up one of the things I like about catalina and has influenced my
thoughts on cocoon2 lately. Catalina on one hand provides a very clean
implementation of a webserver/serlvet engine; but on the other provides a
very clean path to replace, extend and/or enhance existing pieces of it.
Granted, 80% of those downloading it, will never add a single line of code
to catalina itself; but for the 20% that need to, it is really great to work

My thoughts on the sitemap are the same way. It would be best to create a
map that served 80% of those downloading it, in an easy and direct manner.
But, it should also allow others enought rope to hang themselves properly.

> Hmmm, this will create pain in Cocoon users that need to choose what
> sitemap schema to use before having played with the technology.
> I think of this more as a "last resort" type of thing and mainly for
> ourselfs developers: to simplify development of the sitemap 
> interpreter.

While I like the idea that there may be multiple sitemap implementations, I
_VERY_ much agree that there needs to be a _SINGLE_ standard default one.
This isn't much different than what we talked about above with Catalina.
Catalina will distribute based around a web.xml for the forseeable future;
but due to its design, I could create a version that loads sitemap.xml using
my code instead by changing one line in server.xml.

This also brings up another point. Doesn't this mean that we're now going to
have both a cocoon.xconf and sitemap.xml? Aren't we going to need a way to
get the parts of the engine initialized before loading the sitemap.

This also comes up, because it seems from the really basic questions that
come thru the list that it might be useful to check during our servlet init
function to make certain that specific jars are available and their version
info--xerces provides this, I'm not sure about xalan. As well as a basic
check that xerces is loaded before parser.jar. I'd even be willing to write
this for both cocoon2 and cocoon1.

Paul Lamb

View raw message