[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