You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Josias Thöny <jo...@wyona.com> on 2006/03/09 11:59:56 UTC
Re: svn commit: r383510 -
/lenya/trunk/src/java/org/apache/lenya/cms/publication/templating/PublicationTemplateManagerImpl.java
On Thu, 2006-03-09 at 11:29 +0100, Andreas Hartmann wrote:
> Thorsten Scherler wrote:
> > El jue, 09-03-2006 a las 09:45 +0100, Andreas Hartmann escribió:
> >> thorsten@apache.org 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.
IMHO shared resources should not be in the content-dir anyway, because
they are not really content (they cannot be created and edited in
lenya). And so far fallback was working for those shared resources which
seems right to me.
But for the "real" content resources (the ones in the authoring and live
dirs) I would not allow fallback for the reasons Andreas gave.
Josias
>
> >> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r383510 -
/lenya/trunk/src/java/org/apache/lenya/cms/publication/templating/PublicationTemplateManagerImpl.java
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 09-03-2006 a las 11:59 +0100, Josias Thöny escribió:
> On Thu, 2006-03-09 at 11:29 +0100, Andreas Hartmann wrote:
> > Thorsten Scherler wrote:
> > > El jue, 09-03-2006 a las 09:45 +0100, Andreas Hartmann escribió:
> > >> thorsten@apache.org 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.
>
> IMHO shared resources should not be in the content-dir anyway, because
> they are not really content (they cannot be created and edited in
> lenya). And so far fallback was working for those shared resources which
> seems right to me.
> But for the "real" content resources (the ones in the authoring and live
> dirs) I would not allow fallback for the reasons Andreas gave.
...but we are *doing* this already!
http://svn.apache.org/viewcvs.cgi/lenya/trunk/src/webapp/lenya/resources.xmap?view=markup
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org