[Dachs-support] Duplicate entries in root.html
Markus Demleitner
msdemlei at ari.uni-heidelberg.de
Fri Sep 25 12:14:07 CEST 2015
Hi Carlos,
On Fri, Sep 25, 2015 at 11:38:59AM +0200, Carlos Brandt wrote:
> For each catalog I have published there are two entries being shown on the
> frontpage (root.html). First question: how do I debug that? Where should I
> look for the source of such issue? Second question: can I ask for a
> "refresh/reload" of all the references?
First off, the reason for what you're seeing is:
> <service id="cone" allowed="scs.xml,form">
[...]
> <publish render="scs.xml" sets="local"/>
> <publish render="form" sets="local"/>
What you're telling DaCHS here is that it should put two things into
the local service roster: One link to the service with the cone
search renderer, and one with the form renderer.
Since a browser can't speack SCS, the link to the cone search service
will appear "bad" (you should get a weird-looking XML error message,
though; if not, that's a DaCHS bug).
In short: You shouldn't have protocol services on the front page.
The standard pattern for service registration is more like this:
<publish render="scs.xml" sets="ivo_managed"/>
<publish render="form" sets="local,ivo_managed"/>
-- this tells DaCHS to have a link to the nice, browser-ready form
service on the front page, and to report to the registry where the
cone search service is so clients actually understanding SCS can find
it. [For expermination and experts, the SCS link is still
discoverable through a web browser in "Service Info"]
To update the publication after you changed the RD, simply run gavo
pub again.
Then:
> can I ask for a
> "refresh/reload" of all the references?
You *could* run gavo pub -a, which re-publishes everything that's
been published before, but I don't recommend that in halfway normal
situations. That's more for when central metadata of all your
services change -- the contact e-mail or telephone, for instance. It
will touch all your records, so all of them will show up as changed
in things like the Registry RSS
(http://dc.zah.uni-heidelberg.de/registryrss/q/rss/info) (unless you
use the -k flag... but I'm digressing).
Finally:
> First question: how do I debug that? Where should I
> look for the source of such issue?
Uh, I should really be writing solid docs on nevow templates in DaCHS.
But to give a starting point -- the root page by default is generated
through a nevow template called root.html (that, at least, explained
in the operator's guide). If you have the "plain" opening page,
there's this in there:
<div id="title-list"
n:data="chunkedServiceList" n:render="sequence" class="panel">
<n:invisible n:pattern="item">
<h3><n:invisible n:render="string" n:data="0"/>...</h3>
<ul n:data="1" n:render="sequence">
So, how to read this?
The n:data on the div tells nevow to pull in "context data". The
n:render then tells it what to do with this data (in this case, apply
the child element as a template to each item of the sequence). Both
of these attributes are converted to function calls on a partiular
object fairly directly.
For n:data list this, this would call a function
data_chunkedServiceList on the renderer.
However, it's not obvious what the renderer on the root page is;
believe me for the moment that it works out to be the static renderer
on //service#root; as in DaCHS, renderers are a bit ghostly, render
function in RD end up being on the services themselves (or hardcoded
in source code). How that service is defined you can view using
gavo admin dumpDF //services. Scrolling to id="root" in there,
you'll find:
<customDF name="chunkedServiceList">
rd = base.caches.getRD("__system__/services")
if not hasattr(rd, "chunkedServiceList"):
from gavo.registry import servicelist
rd.chunkedServiceList = servicelist.getChunkedServiceList()
return rd.chunkedServiceList
</customDF>
-- which, apart from some caching magic, essentially just calls
gavo.registry.servicelist.getChunkedServiceList.
That, unfortunately, is some mouldy code that made some sense when
I wrote it eight years ago but now should be replaced with something
more explicit. With a bit of patience you'll work out that all it
does is query the dc.resources_join view, which is what actually
feeds this and where you could figure out what DaCHS actually
believes about your services.
In case you're using a root page derived from the more modern
root-tree.html, I believe you'll have an easier time to figure out
how things work, as it's altogether less convolved (but then it's
javascript-heavy...).
Did that help a bit? I *really* need to write a piece on templates
in DaCHS, I know.
Sorry I keep procrastinating that,
Markus
More information about the Dachs-support
mailing list