[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