cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: [RT] Negative Matching Constructs && Mime Type Matching
Date Thu, 29 Nov 2001 13:30:05 GMT
On Wed, 28 Nov 2001, Stefano Mazzocchi wrote:

> 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]

Good point. This in fact would solve it for all environments as well as
for other Blocks or Composers (Avalon speaking) being able to use such a
Component.

Giacomo


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message