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>
>
I think such a construct would only make sense for automatic link
crawling which is done by the CLI for example to generate the docs.
I think such a negative matching is not required for usual Web sites.
For the CLI you can of course use filters, like we do for our
documentation build system. The "links view" is defined by a filter
stylesheet which filters all URIs which should not be handled by
Cocoon.
Carsten
> 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: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}">
> <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>
>
> 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/>
>
> 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. 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:
>
> <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.
>
> The only need for the mime-type would be when your URI does not
> have an extension, or it is
> non-standard.
>
>
> --
>
> "Those who would trade liberty for
> temporary security deserve neither"
> - Benjamin Franklin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
