[EMAIL PROTECTED] wrote:
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
Yes, you could access the raw image that way to add a <img src=""/> to
your xhtml (Document|Content Item|?), but you could also access the
images (Document|Content Item|?) the same way that you access a xhtml
(Document|Content Item|?). As Andreas pointed out, most would likely
just want a request for {$contextprefix}/{$pubID}/{$area}/{$imageid} to
match:
<map:match pattern="**.png">
<map:redirect-to uri="cocoon://modules/images/{1}.png"/>
</map:match>
Some might want to show the image on a .html page with its metadata.
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.
Yeah, but this sounds to me like we are attaching the term document to a
single ext (html, pdf, or whatever). What about when we have multiple
forms of a "Document" (Using the def in 1.4-repository-api.pdf), for
example .odt? Some clients might want the .html representation of the
"Document" while others might want the .odt representation. This
doesn't mean that the .odt request is for an asset.
I like the "Document" (perhaps a better name is needed) idea:
A document represents a language version of a content item. It can hold
any kind of textual or binary data.
This fits 1.2 ideas of Documents and Assets. There should be no need
for a standard file asset. The Asset module would take care of the
basics. If you need more functionality (such as svg image resize|html
representation of odt) make a module that handles it (like the images
module|opendocument module).
If content items need to own other content items, we are really talking
about structure which should be a separate module (sitetree?).
--Doug
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
