On 2/3/06, Doug Chestnut <[EMAIL PROTECTED]> wrote:
> [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.
So the "assets" module retrieves the file, but if the publication
includes the "images" module, then the "assets" module passes control
to the "images" module.
<map:select type="module-exists">
<map:when test="images">
<map Test for image extensions>
<map:mount src="images"/>
<!-- ELSEs -->
> > 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.
Could this be handled by code like above?
> 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).
There is another thread about terminology. It sounds like you want
"Language Version" to be called "Document". It seems likely the
parent (All versions and languages of a Document) will be called
"Content Item", but I am uncertain if the term for the
language-specific nodes should not have "Language" in the name.
> If content items need to own other content items, we are really talking
> about structure which should be a separate module (sitetree?).
My idea is all structure is handed by the Sitetree Generator which
uses a specified Index to generate the flat or hierarchical structure.
The hierarchical information is children storing the ParentUNID. A
special table "ParentUNID - ChildUNID" is needed for performance, so
parent.getChildren() does not search the entire datastore.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
