[Dachs-support] Duplicate entries in root.html

Carlos Brandt carloshenriquebrandt at gmail.com
Fri Sep 25 16:57:58 CEST 2015


Genio.
:D

Yep. That helped. Now I understand better what's going on there.

By all means, my mistake was pretty stupid. When I restored the services, I
couldn't relate (didn't see) the "local" for scs with the duplicity at the
front page. Sorry.

Anyway.. thank you.

BTW: templates would be awesome.

[]
Carlos

On Fri, Sep 25, 2015 at 12:14 PM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> 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
>
> _______________________________________________
> Dachs-support mailing list
> Dachs-support at g-vo.org
> http://lists.g-vo.org/cgi-bin/mailman/listinfo/dachs-support
>



-- 
Your choices are half chance, so are everybody else's.
-------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.g-vo.org/pipermail/dachs-support/attachments/20150925/de0e93f1/attachment-0001.htm>


More information about the Dachs-support mailing list