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: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
