cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT]: Restructuring the build system
Date Mon, 19 Nov 2001 21:42:09 GMT
Carsten Ziegeler wrote:
> 
> Gianugo Rabellino wrote:
> >
> > > If we have a mechanism which is able to add something to the
> > cocoon.xconf
> > > and the sitemap, we should use this for the core components as well.
> > > Rather then defining a sitemap which has all the component
> > definitions in
> > > it already, this will be assembled during the build. Same applies
> > > to the cocoon.xconf.
> >
> >
> > Sure thing. And now that I think about it, I'm wondering if we are
> > trying once more to reinvent the wheel: since what we want to do is
> > after all an XML transformation of two files, why don't we just write
> > two stylesheets (say cocoon.xconf.xsl and sitemap.xmap.xsl) for each
> > optional package? They should be trivial to write: if they are present
> > the transformations will take place and modify the configs accordingly.
> > This seems to me the cleanest and fastest way to achieve the result.
> > What do you think?
> >
> So, the sitemap and cocoon.xconf are build-up from an base file which
> is processed by several stylesheets. Hmm, this is an interesting idea!
> One the one hand, I like it, because no java class has to be written
> for it, no addition libs are needed etc.
> One the other hand, the configuration of the optinal components is
> done by a stylesheet. This might look a little bit wired.
> 
> But your stylesheet approach is a good idea! I'll think about it.

Just some historical context: Stylebook was the first to have a sitemap.
Then it became complex and Pier implemented a stylesheet to go from a
"book" file to the sitemap.

Result: nobody knows that stylebook had a sitemap that could be written
by hand because the stylesheet removed all the visibility to it.

So, stylesheets might be cool for us because we don't have to write
sitemap infoset augmenting tools, but this might remove visibility to
optional components and make it harder for people to add new ones.

These days, I'm diving *very* deep into Mozilla code and they have the
same problem: they have a bunch of RDF files to describe what URN
connect to what component and what properties it has.

But to install a new component (it could be a skin, a locale or an
entire application), you just have to add a line into the file
[mozilla-home]/chrome/installed-chrome.txt

content,install,url,jar:resource:/chrome/multiviews.jar!/content/multiviews/
skin,install,url,jar:resource:/chrome/multiviews.jar!/skin/modern/multiviews/

and the browser will rebuild the RDF files automatically (haven't tried
that but the docs say this).

I'm incredibly happy to find so many similarities between cocoon and
mozilla, but this is something for the next email.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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


Mime
View raw message