[EMAIL PROTECTED] wrote:
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 -->
No, they are just "Resource Types"
(http://lenya.apache.org/1_4/reference/resource-types.html).
Just as xhtml, cforms, opendocument, homepage, etc are resource types.
We would just be adding and assets resource type and images resource type.
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?
not sure which code. I don't think that we currently have support for
different extensions/mimetype versions of a Document|Content
Item|Resource in 1.4. I think that this would be desirable
functionality though. It would need to be handled by the "resource
type" modules though.
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.
I actually don't like the term document, as in my head the term document
doesn't fit some of the objects that I might want to store in a cms
(image, template, executable, etc...).
To be honest, I don't really care what the term is, as long as we have
defined the definition. ;)
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.
I have always thought of this as a task for an rdf db. The
relationships could just be stored in the db as tuples. The various
sitetrees could just be generated by TQL queries. But, I guess this is
what you are purposing as well, I guess we could even use a lucene index
for this.
--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]
