You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Jörn Nettingsmeier <po...@uni-duisburg.de> on 2006/08/28 17:07:50 UTC
template-fallback question [was Re: i18n revisited...]
doug, maybe you can comment on this?
Andreas Hartmann wrote:
> Jörn Nettingsmeier wrote:
>> i've had problems with i18n catalogue merging in templated
>> publications.
>>
>> what do you think about the following approach:
>>
>> each publication mounts the globally defined i18n.xmap into its own
>> sitemap, which then runs in the "context" of the current sitemap as
>> far as the fallback resolver is concerned. this way, each publication
>> has a "give me your catalogues" callback via the "i18n-catalogue/**"
>> match.
>
> This sounds useful.
>
>> the i18n sitemap now checks if there is a catalogue in the current
>> publication and loads it. then it calls parent://i18n-catalogue/{1}
>> [*]. the same operation takes place one level higher, until eventually
>> all catalogues are merged.
>>
>> all this happens in an aggregator. when all parts are gathered
>> together, a simple xsl transform folds them into a common <catalogue>
>> element and returns the complete catalogue.
>>
>> [*] the question is how to get at parent://. i know of
>> template-fallback:// - will it do what i need?
>
> Yes, it was built for this purpose.
>
>> i think yes, but what does template-fallback:// yield when it's called
>> at the root of the template tree? if it returns nothing, then it's
>> fine. if it returns the current resource, we have a loop. can anyone
>> comment?
>
> I guess it returns the current resource, but I'm not sure.
i looked in the getSource method, and i found this snippet:
Publication pub = pubMgr.getPublication(publicationId);
ok, so this is the current publication.
//Get the template publication
String pubTemplateId = pub.getTemplateIds()[0];
if (pubTemplateId.length() > 0)
pub = pubMgr.getPublication(pubTemplateId);
iiuc, pub is re-defined only if there is a template pub.
there are no more checks, so i would assume that the following code does
indeed return the current resource:
if (pub.exists()) {
ExistingSourceResolver resolver = new ExistingSourceResolver();
templateManager.visit(pub, path, resolver);
resolvedUri = resolver.getURI();
}
sigh. it seems that andreas is right, template-fallback:// will return
the current resource if no template exists. is there a specific reason
for this? it sounds dangerous to me...
another question: i thought that template-fallback walks through the
ancestors until it finds a resource, but i did not see any recursion in
the code - it looks like it will only try the direct ancestor. is that
correct?
i wonder if we need an explicit input module or source factory that will
return the parent resource, regardless of its existence. in the case of
i18n catalogue merging, i'd rather do away with too much implicit magic
and walk up the template tree one step after the other. wdyt?
>
>>
>> *.*
>>
>> additionally, i'd like to treat the catalogues of the lenya gui and of
>> the publications differently, for two reasons:
>>
>> * it does not make sense to have your publication catalogue in a file
>> named "cmsui.xml", since you're using it for live content, not the cms
>> ui.
>
> Both should be possible. But IMO it is even more important to allow
> i18n catalogues in modules. And you might want to override e.g. module
> menu items with publication-specific ones ("Add article" instead of
> "Add XHTML document").
>
>> * it will avoid key clashes. if a publication wishes to re-use
>> messages from lenya's cmsui.xml, it can always say so explicitly by
>> using <i18n:text catalogue="cmsui" key="cancel"/>.
>
> +1
>
>> so i propose to have one catalogue named "cmsui.xml" and one named
>> "content.xml". wdyt?
>
> Hmm, "content" is too specific IMO. What about "website"?
>
> -- Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: template-fallback question [was Re: i18n revisited...]
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Doug Chestnut wrote:
> Hi Jörn,
>
> Jörn Nettingsmeier wrote:
>> doug, maybe you can comment on this?
>>>> [*] the question is how to get at parent://. i know of
>>>> template-fallback:// - will it do what i need?
>>>
>>>
>>> Yes, it was built for this purpose.
>>>
>>>> i think yes, but what does template-fallback:// yield when it's
>>>> called at the root of the template tree? if it returns nothing, then
>>>> it's fine. if it returns the current resource, we have a loop. can
>>>> anyone comment?
>>>
>>>
>>> I guess it returns the current resource, but I'm not sure.
>
> It should return the parent templates resource. If there is no parent
> template, return the resource from the webapp context.
>
> I haven't tested it, but a quick look at the source confirms this.
ah, yes, thanks for the help. i now realize i got it all wrong until
andreas told me about the visitor pattern...
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: template-fallback question [was Re: i18n revisited...]
Posted by Doug Chestnut <dh...@virginia.edu>.
Hi Jörn,
Jörn Nettingsmeier wrote:
> doug, maybe you can comment on this?
>
> Andreas Hartmann wrote:
>
>> Jörn Nettingsmeier wrote:
>>
>>> i've had problems with i18n catalogue merging in templated publications.
>
> >>
>
>>> what do you think about the following approach:
>>>
>>> each publication mounts the globally defined i18n.xmap into its own
>>> sitemap, which then runs in the "context" of the current sitemap as
>>> far as the fallback resolver is concerned. this way, each publication
>>> has a "give me your catalogues" callback via the "i18n-catalogue/**"
>>> match.
>>
>>
>> This sounds useful.
>>
>>> the i18n sitemap now checks if there is a catalogue in the current
>>> publication and loads it. then it calls parent://i18n-catalogue/{1}
>>> [*]. the same operation takes place one level higher, until
>>> eventually all catalogues are merged.
>>>
>>> all this happens in an aggregator. when all parts are gathered
>>> together, a simple xsl transform folds them into a common <catalogue>
>>> element and returns the complete catalogue.
>>>
>>> [*] the question is how to get at parent://. i know of
>>> template-fallback:// - will it do what i need?
>>
>>
>> Yes, it was built for this purpose.
>>
>>> i think yes, but what does template-fallback:// yield when it's
>>> called at the root of the template tree? if it returns nothing, then
>>> it's fine. if it returns the current resource, we have a loop. can
>>> anyone comment?
>>
>>
>> I guess it returns the current resource, but I'm not sure.
It should return the parent templates resource. If there is no parent
template, return the resource from the webapp context.
I haven't tested it, but a quick look at the source confirms this.
>
>
> i looked in the getSource method, and i found this snippet:
>
> Publication pub = pubMgr.getPublication(publicationId);
TemplateFallbackSourceFactory.java:
public class TemplateFallbackSourceFactory extends FallbackSourceFactory {
public TemplateFallbackSourceFactory() {
super();
}
protected URIResolver getSourceVisitor() {
return new ExistingAncestorSourceResolver();
}
}
FallbackSourceFactory.java:
[...]getSource[...]
Publication pub = pubMgr.getPublication(factory,
publicationId);
if (pub.exists()) {
URIResolver resolver = getSourceVisitor();
templateManager.visit(pub, path, resolver);
resolvedUri = resolver.getURI();
}
[...]
ExistingAncestorSourceResolver.java:
public void visit(Source source) {
if (source.exists()) {
matches++;
if (matches == 2) {
this.uri = source.getURI();
}
}
}
PublicationTemplateManagerImpl.java:
[...]
public void visit(Publication publication, String path,
SourceVisitor visitor) {
SourceResolver resolver = null;
try {
resolver = (SourceResolver)
this.manager.lookup(SourceResolver.ROLE);
String[] baseUris = getBaseURIs(publication);
for (int i = 0; i < baseUris.length; i++) {
String uri = baseUris[i] + "/" + path;
if (getLogger().isDebugEnabled()) {
getLogger().debug("Trying to resolve URI [" + uri +
"]");
}
Source source = null;
try {
source = resolver.resolveURI(uri);
visitor.visit(source);
} catch (Exception e) {
getLogger().error("Could not resolve URI [" + uri +
"]: ", e);
throw e;
} finally {
if (source != null) {
resolver.release(source);
}
}
}
[...]
>
> ok, so this is the current publication.
>
> //Get the template publication
> String pubTemplateId = pub.getTemplateIds()[0];
> if (pubTemplateId.length() > 0)
> pub = pubMgr.getPublication(pubTemplateId);
>
> iiuc, pub is re-defined only if there is a template pub.
> there are no more checks, so i would assume that the following code does
> indeed return the current resource:
>
> if (pub.exists()) {
> ExistingSourceResolver resolver = new ExistingSourceResolver();
> templateManager.visit(pub, path, resolver);
> resolvedUri = resolver.getURI();
> }
>
> sigh. it seems that andreas is right, template-fallback:// will return
> the current resource if no template exists. is there a specific reason
> for this? it sounds dangerous to me...
>
> another question: i thought that template-fallback walks through the
> ancestors until it finds a resource, but i did not see any recursion in
> the code - it looks like it will only try the direct ancestor. is that
> correct?
>
> i wonder if we need an explicit input module or source factory that will
> return the parent resource, regardless of its existence. in the case of
> i18n catalogue merging, i'd rather do away with too much implicit magic
> and walk up the template tree one step after the other. wdyt?
>
>
>
>
>
>>
>>>
>>> *.*
>>>
>>> additionally, i'd like to treat the catalogues of the lenya gui and
>>> of the publications differently, for two reasons:
>>>
>>> * it does not make sense to have your publication catalogue in a file
>>> named "cmsui.xml", since you're using it for live content, not the
>>> cms ui.
>>
>>
>> Both should be possible. But IMO it is even more important to allow
>> i18n catalogues in modules. And you might want to override e.g. module
>> menu items with publication-specific ones ("Add article" instead of
>> "Add XHTML document").
>>
>>> * it will avoid key clashes. if a publication wishes to re-use
>>> messages from lenya's cmsui.xml, it can always say so explicitly by
>>> using <i18n:text catalogue="cmsui" key="cancel"/>.
>>
>>
>> +1
>>
>>> so i propose to have one catalogue named "cmsui.xml" and one named
>>> "content.xml". wdyt?
>>
>>
>> Hmm, "content" is too specific IMO. What about "website"?
>>
>> -- Andreas
>>
>>
>> ---------------------------------------------------------------------
>> 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: template-fallback question [was Re: i18n revisited...]
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Andreas Hartmann wrote:
> Jörn Nettingsmeier wrote:
>
> [...]
>
>>> I guess it returns the current resource, but I'm not sure.
>>
>> i looked in the getSource method, and i found this snippet:
>>
>> Publication pub = pubMgr.getPublication(publicationId);
>>
>> ok, so this is the current publication.
>>
>> //Get the template publication
>> String pubTemplateId = pub.getTemplateIds()[0];
>> if (pubTemplateId.length() > 0)
>> pub = pubMgr.getPublication(pubTemplateId);
>>
>> iiuc, pub is re-defined only if there is a template pub.
>> there are no more checks, so i would assume that the following code
>> does indeed return the current resource:
>>
>> if (pub.exists()) {
>> ExistingSourceResolver resolver = new ExistingSourceResolver();
>> templateManager.visit(pub, path, resolver);
>> resolvedUri = resolver.getURI();
>> }
>>
>> sigh. it seems that andreas is right, template-fallback:// will return
>> the current resource if no template exists. is there a specific reason
>> for this? it sounds dangerous to me...
>
> I guess we should change it.
+1 unless someone (doug?) has done this for a reason i don't currently
understand.
>> another question: i thought that template-fallback walks through the
>> ancestors until it finds a resource, but i did not see any recursion
>> in the code - it looks like it will only try the direct ancestor. is
>> that correct?
>
> That's done by the ExistingSourceResolver, which is a SourceVisitor
woof. that's subtle. especially since it is wrapped up in an extra
method with an innocent name, even though it's used only once... i just
read past it, looking for some kind of recursion.
> (see GoF visitor pattern for more information).
i thought i knew it, but i grabbed the book anyway to find out what the
special "gof" variant is. it eventually dawned on me that you probably
meant "gang of four".... :)
>> i wonder if we need an explicit input module or source factory that
>> will return the parent resource, regardless of its existence. in the
>> case of i18n catalogue merging, i'd rather do away with too much
>> implicit magic and walk up the template tree one step after the other.
>> wdyt?
>
> I guess this makes sense. Maybe we need a generator which generates a
> list of all existing versions of a resource in the template hierarchy?
that would ease the design a little. my current proposal implies a lot
of boilerplate code, since each publication must mount the global
i18n.xmap so that the "catalogue callback" is available at each level of
inheritance. it would be a lot nicer to have some central code like we
currently have.
but how can we make this fit gracefully into sitemap semantics? afaik
there are no iteration statements, and i would hate to delegate that to
an external mechanism such as xsp again.
i think for now the easiest solution is to introduce another source
factory named "template" that will only look in the direct ancestor.
recursion can be handled as i described above. the downside is some
boilerplate code in the publication sitemap, but the upside is that the
publication can do things differently if it wants by not mounting the
default i18n.xmap and providing its own code.
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: template-fallback question [was Re: i18n revisited...]
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier wrote:
[...]
>> I guess it returns the current resource, but I'm not sure.
>
> i looked in the getSource method, and i found this snippet:
>
> Publication pub = pubMgr.getPublication(publicationId);
>
> ok, so this is the current publication.
>
> //Get the template publication
> String pubTemplateId = pub.getTemplateIds()[0];
> if (pubTemplateId.length() > 0)
> pub = pubMgr.getPublication(pubTemplateId);
>
> iiuc, pub is re-defined only if there is a template pub.
> there are no more checks, so i would assume that the following code does
> indeed return the current resource:
>
> if (pub.exists()) {
> ExistingSourceResolver resolver = new ExistingSourceResolver();
> templateManager.visit(pub, path, resolver);
> resolvedUri = resolver.getURI();
> }
>
> sigh. it seems that andreas is right, template-fallback:// will return
> the current resource if no template exists. is there a specific reason
> for this? it sounds dangerous to me...
I guess we should change it.
> another question: i thought that template-fallback walks through the
> ancestors until it finds a resource, but i did not see any recursion in
> the code - it looks like it will only try the direct ancestor. is that
> correct?
That's done by the ExistingSourceResolver, which is a SourceVisitor
(see GoF visitor pattern for more information).
> i wonder if we need an explicit input module or source factory that will
> return the parent resource, regardless of its existence. in the case of
> i18n catalogue merging, i'd rather do away with too much implicit magic
> and walk up the template tree one step after the other. wdyt?
I guess this makes sense. Maybe we need a generator which generates a
list of all existing versions of a resource in the template hierarchy?
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org