Thorsten Scherler wrote:
El jue, 09-03-2006 a las 09:45 +0100, Andreas Hartmann escribió:
[EMAIL PROTECTED] wrote:
Author: thorsten
Date: Mon Mar 6 02:50:01 2006
New Revision: 383510
URL: http://svn.apache.org/viewcvs?rev=383510&view=rev
Log:
Adding the content dir to the fallback URIs like described in
http://marc.theaimsgroup.com/?l=lenya-dev&m=114142602919893&w=2. This fixes the
second part of the 'external' resources/asset preview.
Modified:
lenya/trunk/src/java/org/apache/lenya/cms/publication/templating/PublicationTemplateManagerImpl.java
Modified:
lenya/trunk/src/java/org/apache/lenya/cms/publication/templating/PublicationTemplateManagerImpl.java
URL:
http://svn.apache.org/viewcvs/lenya/trunk/src/java/org/apache/lenya/cms/publication/templating/PublicationTemplateManagerImpl.java?rev=383510&r1=383509&r2=383510&view=diff
==============================================================================
---
lenya/trunk/src/java/org/apache/lenya/cms/publication/templating/PublicationTemplateManagerImpl.java
(original)
+++
lenya/trunk/src/java/org/apache/lenya/cms/publication/templating/PublicationTemplateManagerImpl.java
Mon Mar 6 02:50:01 2006
@@ -111,10 +111,15 @@
protected String[] getBaseURIs(Publication publication) {
List uris = new ArrayList();
+ String contentDir = null;
Publication[] publications = getPublications(publication);
for (int i = 0; i < publications.length; i++) {
uris.add(getBaseURI(publications[i]));
+ contentDir = publications[i].getContentDir();
+ if (contentDir != null){
+ uris.add(contentDir);
+ }
Thorsten, does this really make sense? IMO it is very dangerous.
The fallback has a well-defined meaning [1]. If we add the content
directory to the list of URLs to traverse, we have two different
locations in the same publication that could match.
Yeah, but I do not see a problem here, that is the concept of fallback,
or? ;)
No, the concept of fallback is falling back from the publication to its
template(s) and finally to the core.
Using [1] for resources (like images/assets):
1. content-dir://resources/shared/images/foo.png
2. context://lenya/pubs/my-pub/resources/shared/images/foo.png
3. context://lenya/pubs/template(my-pub)/resources/shared/images/foo.png
4.
context://lenya/pubs/template(template(my-pub))/resources/shared/images/foo.png
5. ...
6. context://resources/shared/images/foo.png
This would be a whole new concept. I would not extend fallback to
these resources.
Apart from the
danger of clashes, the semantics are totally changed.
Hmm, why? We just added a location which should be checked first. I
neither see possible clashes (since fallback follows "first matched
first taken")
Imagine you have a shared resource in your publication, e.g. your company
logo. Now someone adds a resource with the same path to the content.
Now your comany logo will be overridden by the new resource in all
places! We can't allow interferences between equally named resources
in different locations.
Would you mind explaining why the fallback is the correct location
to implement this behaviour? Thanks a lot!
The fallback is for "Publication Templating", right?
Yes. But it should not apply to content for the reasons mentioned above.
We should find another concept to *explicitely* include content from
other publications (not just templates).
The outsourced content-dir (remember my definition of content is *not*
limit to our "content/{area}" dir but includes any asset -> in my eyes
as well content) is now the "implementation of myPub". MyPub has become
itself a template.
If no foo.png can be found in the content-dir then follow the fallback
road.
wdyt?
Hmmm, I don't really like it :/
IMO fallback should only apply to static resources (XSLT, sitemaps,
shared static images used for layout).
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
