You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Thorsten Scherler <th...@wyona.com> on 2006/03/09 11:19:22 UTC
Re: svn commit: r383510 -
/lenya/trunk/src/java/org/apache/lenya/cms/publication/templating/PublicationTemplateManagerImpl.java
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? ;)
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
> 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")
> 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?
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?
> -- Andreas
>
>
> [1]
> http://lenya.apache.org/1_4/reference/publication-templating/index.html#The+Concept+of+Publication+Templating
>
--
Thorsten Scherler
COO Spain
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
thorsten.scherler@wyona.com thorsten@apache.org
---------------------------------------------------------------------
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 Andreas Hartmann <an...@apache.org>.
Doug Chestnut wrote:
[...]
>> I'd rather allow to include content from other publications (e.g., from
>> the shared publication) explicitly.
> +1
>
> can't xinclude be used for this
Yes, for instance
<xi:include href="lenyadoc://{$pubId}/{$area}/{$language}/{$documentId}"/>
-- 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: r383510 - /lenya/trunk/src/java/org/apache/lenya/cms/publication/templating/PublicationTemplateManagerImpl.java
Posted by Doug Chestnut <dh...@virginia.edu>.
Andreas Hartmann wrote:
> Bob Harner wrote:
>
> [...]
>
>> 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.
>
>
> This raises the issue of addressing documents. At the moment,
> content-related fallback would certainly be based on the document ID:
>
> - look in <mypub> if document /foo/bar:en exists
> - if not, look in <sharedpub> if document /foo/bar:en exists
> - if not => 404
>
> But how would it work with UUIDs?
>
> ----
>
> Actually I don't like this very much, because website editors are
> confronted with the fallback concept (which should IMO be a purely
> internal concept).
>
> I'd rather allow to include content from other publications (e.g., from
> the shared publication) explicitly.
+1
can't xinclude be used for this
>
> -- 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 Andreas Hartmann <an...@apache.org>.
Bob Harner wrote:
[...]
> 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.
This raises the issue of addressing documents. At the moment,
content-related fallback would certainly be based on the document ID:
- look in <mypub> if document /foo/bar:en exists
- if not, look in <sharedpub> if document /foo/bar:en exists
- if not => 404
But how would it work with UUIDs?
----
Actually I don't like this very much, because website editors are
confronted with the fallback concept (which should IMO be a purely
internal concept).
I'd rather allow to include content from other publications (e.g., from
the shared publication) explicitly.
-- 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: r383510 - /lenya/trunk/src/java/org/apache/lenya/cms/publication/templating/PublicationTemplateManagerImpl.java
Posted by Bob Harner <bo...@gmail.com>.
On 3/9/06, Andreas Hartmann <an...@apache.org> 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ó:
> >>>> 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.
> >
> >
> > 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: 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 Andreas Hartmann <an...@apache.org>.
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ó:
>>>> 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.
>
>
> 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
--
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: 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:29 +0100, Andreas Hartmann escribió:
> 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.
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?
>
> >> 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.
...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.
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
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
Re: svn commit: r383510 -
/lenya/trunk/src/java/org/apache/lenya/cms/publication/templating/PublicationTemplateManagerImpl.java
Posted by Josias Thöny <jo...@wyona.com>.
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 Andreas Hartmann <an...@apache.org>.
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.
>> 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
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