Berin Loritsch wrote:
> > 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!
It should be fairly trivial once you know regexp (and I don't!)
> > 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...).
yep
> What did you think about being able to *explicitly* raise an error from the sitemap?
Uh, I probably missed that. What do you mean?
[snip]
> > <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.
so? did you ever had to try to guess an image URI by hand? would anybody
be able to notice that change from a normal browsing experience?
> 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.
yes
> >>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?
Yep. So, do you propose to have a mime-mapper Avalon component?
[note that the Cocoon CLI already performs the reverse mapping between
mime/type and extension, so we need a component that is able to obtain
an extension for a mime type and a mime type from an extension]
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
