cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: [RT] Negative Matching Constructs && Mime Type Matching
Date Tue, 27 Nov 2001 21:08:19 GMT
On Tue, 27 Nov 2001, Berin Loritsch wrote:

> While using Cocoon to generate the developer's docs, I have discovered some use
> cases where a more flexible matcher should be considered.  First, let me outline
> how it works (now that we can follow links....):
> 1) By default, all requests for **.html files are handled by a default pipeline
> 2) We override this default for the developer's docs (have to perform includes for
>      one big document)
> 3) We override this default for externally generated HTML files (i.e. the UML
>      diagrams)
> 4) We override this again for the API docs and return index.xml because it will be
>      overridden later.
> Why are the latter two even necessary?  They didn't used to be, but the URI following
> in Cocoon does not allow me to exclude certain URI paths from Cocoon.  In a way, I
> would like to have a method for negative matching, and a way to perform aggregated
> matching.
> Negative matching basically works so that Cocoon will IGNORE the matched uris.
> For example, if I have a directive that will directly generate a 404 error, I can
> satisfy this requirement like this:
> <map:match pattern="api/**">
> <map:generate-error type="404"/>
> </map:match>
> The Aggregate matching would change the way patterns are expressed.  I know we have
> a RegExp matcher--which is great, but sometimes we want something more familiar:
> <map:match pattern="{api|diagrams}/**">

<map:match pattern="^{api|diagrams}.*$">

If you can use "{api|diagrams}" the above should be familiar as well.

> <map:generate-error type="404"/>
> </map:match>
> This also opens the door for something equally powerful on the positive matching side:
> <map:match pattern="**/images/*.{gif|jpg|png}">

Why should

<map:match pattern="^(.*)/images/([^/]*)[.]{gif|jpg|png}">

not be familiar to someone which is used to regexp? IIRC Stefano mentioned
a similar pattern language some weeks ago.

> <map:select type="parameter">
> <map:parameter name="parameter" value="{3}"/>
> <map:when test="jpg">
> <map:read src="images/{2}.{3}" mime-type="image/jpeg"/>
> </map:when>
> <map:default>
> <map:read src="images/{2}.{3}" mime-type="image/{3}"/>
> </map:default>
> <map:select>
> <map:match>

Well, in the Servlet environment (at least for Tomcat I know for sure) a

  <map:read src="images/{2}.{3}"/>

will be sufficient as the ResourceReader is asked by the Sitemap engine to
state the mime-type which it gots from ServletContext.getMimeType(src).
For the Commandline env we just need to implement something similar to
that (and we can use Tomcats mime mappings in conf/web.xml).

> Of course, then I would want to go a step further and explicitly state my mime-type
> first in the select statement and only have one read.
> <map:mime-type value="image/jpeg"/>
> <map:read/>

Not necessairy if we have a general mime mapping in the CommandlineEnv

> Although, we can apply separation of concerns again.  In other words, mime-type matching
> is not always a concern of the sitemap.  URIs with standard extensions should not need
> to have the mime-type matched by the sitemap.

We sometime don't always want to expose the technology used for a
resource in the URI (IIRC Stefano also mentioned this)

> IOW, standard extensions such as ".pdf",
> ".jpg", ".gif", ".png", ".rtf", etc. should have a table that automatically gets looked
> up and applied to the response.  This can be be a mimetypes file that can either be a
> simple properties file (there are only a flat hierarchy to mime-type resolution) or a
> simplified configuration file:

Tomcat already has such a file (again its in conf/web.xml)

> <mime:entry extension="pdf" type="application/pdf"/>
> Of course It can be grouped for maintenance purposes like this:
> <mime:table group="application">
> <mime:entry extension="pdf" type="pdf"/>
> </mime:table>
> <mime:table group="image">
> <mime:entry extension="jpg" type="jpeg"/>
> <mime:entry extension="gif" type="gif"/>
> </mime:table>
> The table approach can be further shortened by removing the "type" attribute if it is
> same as the extension.  Keep in mind that command line environments and other yet-to-be
> created environments won't have the same mechanisms for mime-type resolution, and it
> be easy to create a general component that performs the resolution for you.  This way
> of all mime-type declarations can be resolved in a maintainable and uniform manner.


> The only need for the mime-type would be when your URI does not have an extension, or
it is
> non-standard.

And this might be the case if you do CC/PP (or what ever to check the
requesting agent) and want to deliver a html to a
browser, a wml to a wap device, a pdf to an acrobat reader, etc.


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

View raw message