On 3/9/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote: > Thorsten Scherler wrote: > > El jue, 09-03-2006 a las 11:29 +0100, Andreas Hartmann escribió: > >> 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. > > > > > > Hmm, then I have seen a lot of abuse of the fallback concept. ;) > > > > Have a look into the resources*xmaps we have. The assets which are > > content as well are using the fallback. > > > > So if we should use it only for templates so why are we using it for > > assets? > > IMO this is a mistake. It's OK to use fallback in resources-shared.xmap, > but not in resources.xmap. > > > >>>> 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. > > > > ¿? > > > > ...but that is what we are doing right now. > > If you create a myCompany pub as template and add your logo then all > > other pubs using it as template *can* override the logo (which btw makes > > a lot of sense in some cases) by adding a logo to the path. > > Yes, but if they should be able to upload the asset using the GUI > then it shouldn't be referenced using fallback. > > > > ...further ATM it is not possible what you describe. A user cannot > > create a pic in the path resources/shared/... via the gui. A user only > > can create assets ATM and not global assets because we do not provide a > > global asset management. > > > >> > >>>> 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). > > > > locationmap. ;) > > > >>> 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). > > > > Then we should as well change it in the places mentioned above. We > > really need more consistency. > > +1 > > -- Andreas
As usual I may not be following all the subtleties of this discussion, but the fallback mechanism seems to me a very good thing to apply to content, if done properly. Yes, shared resources *should* be managed by the GUI (!), and the obvious implementation would be to have a special publication, maybe called "shared" or "global" or something, that contains that content. Then those people with permission to edit content for that special publication could use the GUI to manage the shared content just like the content of any other publication. The fallback mechanism should be used to let individual publications override such shared content. This would be a beautiful thing if done properly. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
