Stefano Mazzocchi wrote:
> 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....):
>>
>><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:generate-error type="404"/>
>></map:match>
>>
>
> Gosh, I had the *exact* same feeling that we need something in between
> star-matching and regexp-mathing.
That's my point. In fact, it would be Really cool if this hybrid matcher was a wrapper
around the RegExp matcher, and merely did a translation on the pattern!
> I already proposed it and it got rejected, I'd be all for it!!!
No-one said we can't implement a third matcher. It would be worth investigating--then
we have the advantage of seeing which is most useful by natural selection (following
Darwinian theory, which doesn't always apply to every situation...).
What did you think about being able to *explicitly* raise an error from the sitemap?
Sometimes the implied error thing is a pain to deal with. This is especially true if
you
want fine control over your URI space and it is either impossible to exclude a range
using
RegExp, or the resulting match pattern is too complex for any mortal to understand.
The errors I would explicitly like to raise are the 400 series errors:
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed (Although I am not sure that I know how to enforce this at the
sitemap level).
406 Not Acceptable (I have to examine what this is for again--I am going through the
HTTP spec contents...)
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required (disallow chunking on SOAP requests or uploads....)
412 Precondition Failed
413 Request Entity Too Large
414 Request URI Too Long
415 Unsupported Media Type
416 Request Range Not Satisfiable
417 Expectation Failed
And possible the 500 series errors:
500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
>>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>
>>
>
> or even
>
> <map:match patter="**/images/*.{gif|jpeg|png}">
> <map:read src="images/{2}.{3}" mime-type="image/{3}"/>
> </map:match>
>
> since nobody forces you to use three-letters extensions for your URIs :)
True--though it is a common convention.
Note: Giacomo mentioned that the Readers and Serializers are supposed to rely
on the environment's Mime Mapping to handle the cases where it is not
declared either in the component section or the pipeline section.
>>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.
>>
>
> I thought this was already implemented? isn't it?
This is only implemented for the servlet environment. There is no way to have a
standard suite
of mime-mappings independently of the environment. IOW, the Servlet environment has
it's way,
the CLI environment has another way (or ignores it), a Block embedded Cocoon would
have yet
another way.
Do you see the conundrum?
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
