You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2006/02/02 10:57:28 UTC
Re: svn commit: r372987 - /lenya/trunk/src/modules/svg/sitemap.xmap
Hi Doug,
chestnut@apache.org wrote:
[...]
> + <map:act type="resource-exists-enhanced">
> + <map:parameter name="url" value="fallback://resources/{../2}/{../3}.{../4}"/>
> + <map:parameter name="type" value="file"/>
> + <map:transform src="xslt/scale.xsl">
> + <map:parameter name="url" value="fallback://resources/{../../2}/{../../3}.{../../4}"/>
This doesn't work for me. IIRC Batik can't access Cocoon's source
resolver and therefore can't work with fallback:// URLs. Does it
really work for you?
I'm replacing the fallback:// URL with a call to the fallback
input module, this way the input module does the resolving and
passes a comprehensible URL to Batik.
Would you mind testing it with the fallback:// URL again?
Beware that the pipeline is caching :)
Thanks a lot,
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: images module
Posted by so...@apache.org.
On 2/3/06, Doug Chestnut <dh...@virginia.edu> wrote:
> solprovider@apache.org wrote:
> > On 2/3/06, Doug Chestnut <dh...@virginia.edu> wrote:
> >>solprovider@apache.org wrote:
> >>>On 2/3/06, Andreas Hartmann <an...@apache.org> 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.
I think Resource Types are moving to Modules; there have been
references to Resource Type Modules on the ML. So...
The "xhtml" Module handles standard documents.
The "homepage" Module handles the homepage if it is included in a
publication, otherwise the homepage defaults to the "xhtml" Module.
The "blog" Module handled blog documents.
The "product" Module handles the product resource type.
I just wrote an "application" Module for recording completion of
phases of projects. The records should have been a Resource Type, and
used the standard datastore. (Because of security and other specs, it
was easier to keep the data in the Usecase/Module with Lenya 1.2, but
I would design it differently with Lenya 1.4.)
> >>>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.
The code passing control from one module to another if the more
specific module exists and the request meets certain specs.
> 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.
> > [...]
> >>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.
Document-based Databases (such as JCR) have many advantages over
Relational (Table-based) Databases. Relational Databases can offer
better performance, but that is rarely an issue today unless there
will be millions of records/documents. For Lenya, we are moving to
flat storage, which simulates Relational Database MUST do it, but we
gain the flexibility that each node (Document) can have its own
fields/items/properties/children.
For the parent-child relations, children are added to the parent by
adding a property (or multiple properties if multiple parents are
allowed) to the child document. We could search the datastore for all
the children that specify the same parent, but that function is used
so often it is good to maintain/store the information separately for
performance. Yes, that could be a tuple, keying on either the parent
or the child, possible selecting by a group name.
I am not certain Jackrabbit supports TCL, but it has equivalent functionality.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: images module
Posted by Doug Chestnut <dh...@virginia.edu>.
solprovider@apache.org wrote:
> On 2/3/06, Doug Chestnut <dh...@virginia.edu> wrote:
>
>>solprovider@apache.org wrote:
>>
>>>On 2/3/06, Andreas Hartmann <an...@apache.org> 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: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: images module
Posted by so...@apache.org.
On 2/3/06, Doug Chestnut <dh...@virginia.edu> wrote:
> solprovider@apache.org wrote:
> > On 2/3/06, Andreas Hartmann <an...@apache.org> 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: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: images module
Posted by Doug Chestnut <dh...@virginia.edu>.
solprovider@apache.org wrote:
> On 2/3/06, Andreas Hartmann <an...@apache.org> 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: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: images module
Posted by so...@apache.org.
On 2/3/06, Andreas Hartmann <an...@apache.org> 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: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: images module
Posted by Andreas Hartmann <an...@apache.org>.
Doug Chestnut wrote:
>
>
> Andreas Hartmann wrote:
>> Doug Chestnut wrote:
>>
>>>
>>>
>>> Andreas Hartmann wrote:
>>>
>>>> [...]
>>>>
>>>> A random thought:
>>>>
>>>> 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.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: images module
Posted by Doug Chestnut <dh...@virginia.edu>.
Bob Harner wrote:
> On 2/2/06, Doug Chestnut <dh...@virginia.edu> wrote:
>
>>
>>Andreas Hartmann wrote:
>>
>>>Doug Chestnut wrote:
>>>
>>>
>>>>
>>>>Andreas Hartmann wrote:
>>>>
>>>>
>>>>>[...]
>>>>>
>>>>>A random thought:
>>>>>
>>>>>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, and
>> {$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.
>>
>>>Does it make sense to have an "asset" module for generic asset
>>>management functionality, and separate the actual asset resource
>>>types from this module, using plug-in-like interfaces?
>>>We could use a default resource type for assets which are
>>>not handled in a specific way.
>>>
>>>modules/
>>> assets - asset management classes + usecases
>>> images - image resource types, svg, ...
>>> attachment - generic attachment resource type
>>> flash - flash resource type
>>> ...
>>
>>This sounds good.
>>
>>
>>>
>>>[...]
>>>
>>>IMO a major problem is the DocumentBuilder. Unless we can get rid of
>>>it (that would be great), it has to match image URLs as well.
>>
>>"Document" should really be "Object" (DocumentBuilder -> ObjectBuilder,
>>Document -> Object, DefaultDocument -> DefaultObject) and we add
>>something like getRawURL to Object (to get the .odt url instead of the
>>.html, or to get the .jpg url instead of the .html)
>>
>>My knowledge of the api is not to great so I might be way off base here.
>>
>>--Doug
>>
>>
>>>
>>>[...]
>>>
>>>-- Andreas
>>>
>
>
> Maybe don't use the term "Object" -- much too vague. "ContentItem" is
> better, and other CMS's I know of use that term for each "thing the
> CMS manages".
That works, Document is just too descriptive, I wouldn't classify an
image as a document. ContentItem fits :)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: images module (was: Re: svn commit: r372987 - /lenya/trunk/src/modules/svg/sitemap.xmap)
Posted by Bob Harner <bo...@gmail.com>.
On 2/2/06, Doug Chestnut <dh...@virginia.edu> wrote:
>
>
> Andreas Hartmann wrote:
> > Doug Chestnut wrote:
> >
> >>
> >>
> >> Andreas Hartmann wrote:
> >>
> >>> [...]
> >>>
> >>> A random thought:
> >>>
> >>> 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, and
> {$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.
> >
> > Does it make sense to have an "asset" module for generic asset
> > management functionality, and separate the actual asset resource
> > types from this module, using plug-in-like interfaces?
> > We could use a default resource type for assets which are
> > not handled in a specific way.
> >
> > modules/
> > assets - asset management classes + usecases
> > images - image resource types, svg, ...
> > attachment - generic attachment resource type
> > flash - flash resource type
> > ...
> This sounds good.
>
> >
> >
> >[...]
> >
> > IMO a major problem is the DocumentBuilder. Unless we can get rid of
> > it (that would be great), it has to match image URLs as well.
> "Document" should really be "Object" (DocumentBuilder -> ObjectBuilder,
> Document -> Object, DefaultDocument -> DefaultObject) and we add
> something like getRawURL to Object (to get the .odt url instead of the
> .html, or to get the .jpg url instead of the .html)
>
> My knowledge of the api is not to great so I might be way off base here.
>
> --Doug
>
> >
> >
> >[...]
> >
> > -- Andreas
> >
Maybe don't use the term "Object" -- much too vague. "ContentItem" is
better, and other CMS's I know of use that term for each "thing the
CMS manages".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
images module (was: Re: svn commit: r372987 - /lenya/trunk/src/modules/svg/sitemap.xmap)
Posted by Doug Chestnut <dh...@virginia.edu>.
Andreas Hartmann wrote:
> Doug Chestnut wrote:
>
>>
>>
>> Andreas Hartmann wrote:
>>
>>> [...]
>>>
>>> A random thought:
>>>
>>> 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, and
{$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.
>
> Does it make sense to have an "asset" module for generic asset
> management functionality, and separate the actual asset resource
> types from this module, using plug-in-like interfaces?
> We could use a default resource type for assets which are
> not handled in a specific way.
>
> modules/
> assets - asset management classes + usecases
> images - image resource types, svg, ...
> attachment - generic attachment resource type
> flash - flash resource type
> ...
This sounds good.
>
>
>[...]
>
> IMO a major problem is the DocumentBuilder. Unless we can get rid of
> it (that would be great), it has to match image URLs as well.
"Document" should really be "Object" (DocumentBuilder -> ObjectBuilder,
Document -> Object, DefaultDocument -> DefaultObject) and we add
something like getRawURL to Object (to get the .odt url instead of the
.html, or to get the .jpg url instead of the .html)
My knowledge of the api is not to great so I might be way off base here.
--Doug
>
>
>[...]
>
> -- Andreas
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r372987 - /lenya/trunk/src/modules/svg/sitemap.xmap
Posted by Andreas Hartmann <an...@apache.org>.
Doug Chestnut wrote:
>
>
> Andreas Hartmann wrote:
>> [...]
>>
>> A random thought:
>>
>> 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.
Does it make sense to have an "asset" module for generic asset
management functionality, and separate the actual asset resource
types from this module, using plug-in-like interfaces?
We could use a default resource type for assets which are
not handled in a specific way.
modules/
assets - asset management classes + usecases
images - image resource types, svg, ...
attachment - generic attachment resource type
flash - flash resource type
...
> We could add an
> image module (resource type), which treats an image as any other
> resource (xhtml, homepage, opendoc, image, ...) would be treated.
Yes, this sounds like a good idea.
> We would have to add xhtml:img/@src to the linkRewritingTransformer, but
> the link rewriting needs to have this configurability anyway.
Yes, that's true.
IMO a major problem is the DocumentBuilder. Unless we can get rid of
it (that would be great), it has to match image URLs as well.
> Images could just have a nav visibility of false. I guess the biggest
> change would be the addlink usecase. We could make it much more robust
> by allowing others to link to any images in the pub (other pubs as well?).
That sounds good.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r372987 - /lenya/trunk/src/modules/svg/sitemap.xmap
Posted by Doug Chestnut <dh...@virginia.edu>.
Andreas Hartmann wrote:
> [...]
>
> A random thought:
>
> 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. We could add an
image module (resource type), which treats an image as any other
resource (xhtml, homepage, opendoc, image, ...) would be treated.
We would have to add xhtml:img/@src to the linkRewritingTransformer, but
the link rewriting needs to have this configurability anyway.
Images could just have a nav visibility of false. I guess the biggest
change would be the addlink usecase. We could make it much more robust
by allowing others to link to any images in the pub (other pubs as
well?).
--Doug
>
>
> -- Andreas
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r372987 - /lenya/trunk/src/modules/svg/sitemap.xmap
Posted by Andreas Hartmann <an...@apache.org>.
Doug Chestnut wrote:
[...]
>> I'm replacing the fallback:// URL with a call to the fallback
>> input module, this way the input module does the resolving and
>> passes a comprehensible URL to Batik.
> Thanks :)
No problem :)
> The main reason for the commit was to allow shared resources to be
> displayed. On giving this some thought though, the shared resources
> should really just be a part of the template/skin and should be sized
> for the display when created (I guess there are some exceptions to this).
The transition between template/skin-related resources and other resources
is probably quite smooth, I wouldn't handle them in a different way.
In an ideal world, both would be CMS assets and support versioning etc.
This could apply to XSL stylesheets and CSS as well.
> Do we want to incur the extra processing for shared resources?
IMO that should be up to the publication. At the moment, the default pub
adds the ?lenya.module=svg to all image requests using an XSLT, which is
simple and just works. But other publications might use the SVG module only
for images that were uploaded using a special mechanism. In fact, the
pipelines are caching and therefore performance is probably not really an
issue.
A random thought:
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}/..."/>
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r372987 - /lenya/trunk/src/modules/svg/sitemap.xmap
Posted by Doug Chestnut <dh...@virginia.edu>.
Hi Andreas,
Thanks for pointing this out. Sorry about that, I must have been
looking at gifs with I tested this.
Andreas Hartmann wrote:
> Hi Doug,
>
> chestnut@apache.org wrote:
>
> [...]
>
>> + <map:act type="resource-exists-enhanced">
>> + <map:parameter name="url"
>> value="fallback://resources/{../2}/{../3}.{../4}"/>
>> + <map:parameter name="type" value="file"/>
>> + <map:transform src="xslt/scale.xsl">
>> + <map:parameter name="url"
>> value="fallback://resources/{../../2}/{../../3}.{../../4}"/>
>
>
> This doesn't work for me. IIRC Batik can't access Cocoon's source
> resolver and therefore can't work with fallback:// URLs. Does it
> really work for you?
nope, doesn't work for me either. The imput module works like a champ
though.
>
> I'm replacing the fallback:// URL with a call to the fallback
> input module, this way the input module does the resolving and
> passes a comprehensible URL to Batik.
Thanks :)
The main reason for the commit was to allow shared resources to be
displayed. On giving this some thought though, the shared resources
should really just be a part of the template/skin and should be sized
for the display when created (I guess there are some exceptions to this).
Do we want to incur the extra processing for shared resources? If
needed, you could write your own image2svg.xsl in your pub.
WDYT?
>
> Would you mind testing it with the fallback:// URL again?
> Beware that the pipeline is caching :)
>
> Thanks a lot,
>
> -- Andreas
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org