Return-Path: <stefano@apache.org>
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 49581 invoked from network); 26 May 2000 00:22:49 -0000
Received: from pop.systemy.it (194.20.140.28)
  by locus.apache.org with SMTP; 26 May 2000 00:22:49 -0000
Received: from apache.org (pv46-pri.systemy.it [194.21.255.46]) by
 pop.systemy.it (8.8.8/8.8.3) with ESMTP id CAA01708 for
 <cocoon-dev@xml.apache.org>; Fri, 26 May 2000 02:22:46 +0200
Message-ID: <392DAD64.4406935E@apache.org>
Date: Fri, 26 May 2000 00:47:00 +0200
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I)
X-Accept-Language: en,it
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Squaring the sitemap circle...
References: <392C5C09.1FF117DE@apache.org>
 <014401bfc66b$281f3f40$3c108cd4@eddie>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

Ross Burton wrote:
> 
> Well, I take back my idea of writing a GUI editor... :-)

:-)

If you think visually about the sitemap, it could be very similar to UML
visual editing.... wonder if we could "borrow" some code from some open
source UML editors...

> That sitemap rocks big time, far more flexible and includes all of the
> elements I was beginning to miss in the existing sitemap.  I notice
> regexmatching has been included (see - they do have a use!).

Yes, they do. There is no point on leaving them out, because I know
people will ask for it millions of times anyway if we do.
 
> Well:
> 
> I second John Prevost in suggesting that all parameters to components should
> be in a <param> tag or something similar.  For a start, it makes GUI editors
> easier, and seems more like XML to me.
> 
> Matchers.  I had this discussion with Pier last month or so.  You have:
> 
> <process uri="*">
>     <match type="load" greater-then="2.5">
>         <generator type="parser" src="./*.xml" />
>         <filter type="xslt" src="./stylesheet/low-graphics.xsl" />
>         <serializer type="html" />
>     </match>
>     <match type="browser" is="Mozilla5">
>         <generator type="parser" src="./*.xml" />
>         <filter type="xslt" src="./stylesheet/xul-enabled.xsl" />
>         <serializer type="html" />
>     </match>
>     <generator type="parser" src="./*.xml" />
>     <filter type="xslt" src="./stylesheet/general-browser.xsl" />
>     <serializer type="html" />
> </process>
> 
> So, if the load is high then a low graphics stylesheet is applied and the
> page sent.  If the browser is Mozilla then a XUL stylesheet is applied and
> the page sent.  Otherwise, a general stylesheet is applied and the page
> sent.  Can matchers be nested?

Well, to be honest, I don't know. At first it seems as FS, but we had
the same discussion for the JAMES sitemap (yes, people, JAMES will have
an sitemap very similar to this!) and I agreed that nestable matching is
a good thing.

> Do we want to state that matchers return the document when the matcher has
> been applied, or should there be a <return/> tag to send the data to the
> client, so that matcher tags can be smaller?  I'm just not sure there is
> enough logic in the matcher syntax, if we can represent if () {...} else if
> () {...} else {...}  I'll be extremely happy.

the need for a "default" matcher emerged and I agree that the syntax
above can lead to problems for users thinking that the <generator> at
the end is executed no matter what.

Possible solutions are:

  <process uri="*">
     <match type="load" greater-then="2.5">
         <generator type="parser" src="./*.xml" />
         <filter type="xslt" src="./stylesheet/low-graphics.xsl" />
         <serializer type="html" />
     </match>
     <match type="browser" is="Mozilla5">
         <generator type="parser" src="./*.xml" />
         <filter type="xslt" src="./stylesheet/xul-enabled.xsl" />
         <serializer type="html" />
     </match>
     <otherwise>
      <generator type="parser" src="./*.xml" />
      <filter type="xslt" src="./stylesheet/general-browser.xsl" />
      <serializer type="html" />
     </otherwise>
  </process> 

which can be rewritten less verbosely as
  
  <process uri="*">
    <generator type="parser" src="./*.xml"/>
    <match type="load" greater-then="2.5">
     <filter type="xslt" src="./stylesheet/low-graphics.xsl"/>
    </match>
    <match type="browser" is="Mozilla5">
     <filter type="xslt" src="./stylesheet/xul-enabled.xsl"/>
    </match>
    <otherwise>
     <filter type="xslt" src="./stylesheet/general-browser.xsl"/>
    </otherwise>
    <serializer type="html"/>
  </process> 

is this readable enough for everybody? 
   
> Are we standardising on classpath:org.foo.bar or classpath://org.foo.bar?
> I'd say the former.

Cocoon will not use the available URL classes because you can't register
your own URLHandlers easily from a servlet without doing weird hacks. So
we are _cloning_ this functionality by ourselves, wrapping around
existing protocol handlers and letting others to be created.

But we need to define our own syntax for that.

Is the RFC URI powerful enough to handle things like jars, classpath,
cvs and such? I honestly don't know.

I'm wide open to suggestions here.

> What exactly happens here:  <mount uri="bugs/*"
> location="jar:./apps/bugs.cocoon#*" />

Ok, this is a big part of the new paradigms.

This indicates that every request that start with "bugs/" will be mapped
to the web application contained into the "bugs.cocoon" jar archive
(extention doesn't matter, it could be any zipped file).

The -only- constraint (like for any other mounting) is that there must
be a file called /WEB-INF/sitemap.xml located in the zipped file.
(WEB-INF like for Servlet 2.2 WAR archives)

If this file is found, the sitemap is "merged" into the original one and
the component definitions are cascaded.

NOTE:

1) all URIs must be relative during matching, absolute locations have no
meaning for Cocoon given it's servlet nature. Depending on _where_
Cocoon is mapped on the web server, URIs may change. Absolute URIs will
be considered as relative and the beginning slash removed.

2) there is _no_ notion of "file:" protocol. The absence of the file
protocol guarantees that resources on the file system can be located if
both inside or outside archives.

WARNING: #2 could create URI parsing problems on windows, since c:/
could be interpreted as the "c" protocol. Suggestions on these issues
are more than welcome.
 
> I'm happy to work on rewriting the image serializers to use this sitemap and
> anything else I can do after the 3rd.

Don't count on having this implemented soon. This is a working
suggestion on how it should be, but I think we'll move incrementally
from what we have today until we covered up all the functionality
described here rather than doing a major rewrite...

... but if any of you want to do it, I'm not going to stop you :)
 
> I'm going to carry on pondering this tonight....

Same here...

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------