On 2/3/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
> Doug Chestnut wrote:
> > Andreas Hartmann wrote:
> >> Doug Chestnut wrote:
> >>> Andreas Hartmann wrote:
> >>>> We could consider an "images" module, which offers the SVG
> >>>> functionality
> >>>> and image upload usecases. With the new possibility to use a module URL
> >>>> prefix, this could be the starting point of a centralized asset
> >>>> management
> >>>> system.
> >>>> <img src="{$contextprefix}/images/{$pubId}/..."/>
> >>> I like it, but why would we need .../images/... in the path. We
> >>> don't have .../documents/... in the paths for our documents.
> >> That's the URL prefix to call the module. I called it "images"
> >> instead of "image" to make the URL look nice.
> > cool
> > so {$contextprefix}/images/{$pubID}/..."/> would give you the image,
> Yes, though we probably have to support image URLs in the publication
> itself. Many users won't want a special proxy setting for the images.
> But these URLs can be backed up by internal redirects:
>
> $pub/sitemap.xmap:
> <map:match pattern="**.png">
> <map:redirect-to uri="cocoon://modules/images/{1}.png"/>
> </map:match>
>
> > {$contextprefix}/{$pubID}/{$area}/... could give you a page with the
> > image on it?
> > or in the case of an asset
> > {$contextprefix}/{$pubID}/{$area}/... could give you a page with the
> > assets metadata, and a link to the raw asset.
>
> Yes, for example. These pages could be generated by the module as well
> and included in the publication's pipeline for styling.
Is that URL backwards? Yes, an images module could be useful. But
the URL should still be:
/pub/module/parameter
so the "images" module is:
/pub/images/imagename
It could also be handled by having the "live" module use the extension
to pass control to the "images" module. Or have the live module
(/pub//live/image.gif) pass control to the "assets" module
(/pub/assets/image.gif) which passes control to the "images" module
(/pub/images/image.gif). Most of the time, the publication modules
would be inherited from global, and the global modules would check the
publication's datastore before the global datastore to find the
desired image or asset.
The "live" module should only need a match that if the URL is not
asking for a document (has an extension, but the extension is not
"html"), then pass it to the "assets" module. The "assets" module has
a list of extensions that are passed to the "images" module, otherwise
the request is a standard file asset.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
