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
simple
<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 the
> 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
>should
> be easy to create a general component that performs the resolution for you. This
>way 90%
> of all mime-type declarations can be resolved in a maintainable and uniform manner.
Agreed.
> 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.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
