[Dachs-support] Remove frontpage adql/tap links
Carlos Henrique Brandt
carloshenriquebrandt at gmail.com
Wed Apr 27 12:23:43 CEST 2022
Hi Markus,
I have no issues with //tap, you're right, I just wanted to clean the
frontpage a little bit.
I unpublished the //adql resource and *republished* tap to get the new
title of our site (shorter).
So, basically, I did:
```
$ dachs pub -u //adql
$ dachs pub //tap
$ service dachs restart
```
, and I'm happy now.
Thanks for the details on going deep on TAP if I needed to, but I don't
want to mess things up.
I did learn one thing: whenever the docs say "rd", for example in `dachs
pub --help` I thought it
was talking about an RD *file* (e.g, `q.rd`), instead, as you just said, it
is its logical label (e.g, `//tap`).
That's cool.
Thanks,
Carlos
On Wed, Apr 27, 2022 at 8:30 AM Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:
> Hi Carlos,
>
> On Tue, Apr 26, 2022 at 09:18:19PM +0200, Carlos Henrique Brandt wrote:
> > After some "dachs pub ALL/RECURSE" (I don't remember exactly), I got
> some
> > extra links at DaCHS' frontpage:
>
> Yeah, don't do ALL_RECURSE with pub. This probably shouldn't be
> there for dachs pub in the first place because I don't think anyone
> ever has reason to do that: it will publish anything on the system
> that has a publish element.
>
> > - ~/__system__/adql/query/form
> > - ~/__system__/tap/run/info
> >
> > I just want to remove them from the front-page links, how would I do
> that?
>
> In DaCHS, you can always (well: unless you're using vanity URLs) see
> what RDs something comes from by inspecting the first segments of a
> URI, where interactively, you'll usually want to replace
> /__system__/. Publications are always by RD, so to get rid of the
> ADQL form, say
>
> dachs pub -u //adql
>
> The TAP case is harder. It results from this element in //tap:
>
> <publish render="dali" sets="ivo_managed,local">
> <meta name="accessURL">\internallink{tap}</meta>
> </publish>
>
> The local publication there has been in since I've added the tapinfo
> stuff that tells people how to deal with TAP-accessible resources
> (which in turn lets you usefully say <publish sets="local"/> on
> tables).
>
> There's no way to remove the "local" in there from the outside.
> Execept, of course, you can edit
>
> /usr/lib/python3/dist-packages/gavo/resources/inputs/__system__/tap.rd
>
> and say
>
> dachs pub //tap
>
> , but that will break after the next DaCHS update.
>
> And you cannot just say dachs pub -u //tap, because you need that TAP
> service published to the registry for roughly a gazillion reasons.
>
> So... what next? Well: perhaps you can have another look at whether
> you could start to like that link (note that you can override its
> metadata in your userconfig's tapdescription stream)? I'd still
> say it's a good idea to nudge the browser-using masses to possibly
> see the light.
>
> If you can't bring yourself to like it, I could make a tappublication
> stream in userconfig that contains the element above and that
> individual operators can override to their liking. Let me know if I
> should get to work -- I could bake you a beta allowing this some time
> next week.
>
> Oh, and of course there's the quick hack: Just do a psql gavo and run
>
> delete from dc.sets where sourcerd='__system__/tap' and setname='local'
>
> That'll be good until the next time someone runs dachs pub //tap or
> dachs pub ALL. Note that the usual considerations for editing the
> root page
> <http://docs.g-vo.org/DaCHS/templating.html#the-root-template> apply
> in this case, too.
>
> -- Markus
> --
> Dachs-support mailing list
> Dachs-support at g-vo.org
> https://lists.g-vo.org/mailman/listinfo/dachs-support
>
--
Smile, for no reason.
----------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.g-vo.org/pipermail/dachs-support/attachments/20220427/8fcf6323/attachment.htm>
More information about the Dachs-support
mailing list