WebQuery 5.21

Op verzoek van Pauline nog wat extra informatie.

Query syntax:

nieuw: de impliciete OR werkt nu op basis van de veldnaam. Dat betekent dat het niet meer nodig is om daarvoor wq_val te gebruiken. Hiermee is de laatste noodzaak voor het gebruik van wq_fld/wq_val verdwenen. wq_fld en wq_val mogen (liever niet, natuurlijk) nog wel worden gebruikt, met dezelfde effecten als tot nu toe.
de bestaande eisen worden consequenter gecontroleerd
Dat betekent dat veldnamen ook echt moeten bestaan (wordt in mindbsrv nog niet gecontroleerd, aliassen worden in WebQuery nu wel gecontroleerd), Bij wq_fld en wq_lim komt dus nu een foutmelding als de bijbehorende aliasdefinitie (field xxx=yyy in de cgiparm file) er niet is.
Het betekent ook dat direct na een wq_rel een veldnaam moet komen (dus geen wq_rel, wq_max, etc.), en dat wq_val alleen mag volgen op wq_fld, wq_lim of een veldnaam, dus niet op wq_max, wq_rel etc.

Nog even iets over veldnamen en aliassen: WebQuery splitst de veldnaam in een naam en occurrence-informatie op basis van de underscore. Voor updates was dat al lang het geval, maar omdat in het post-minisis tijdperk de query op de zelfde manier naar de backend server gestuurd wordt als de update-gegevens gebeurt dat nu ook voor queries. Zet dus in veldnamen en aliassen nooit een underscore, dat kan later tot fouten leiden. Spaties mogen wel in aliassen, niet in veldnamen.

"field type publikatie=publikatietype" mag wel. WebQuery vervangt dan de alias "type publikatie" door de veldnaam "publikatietype" (bij minisis is dit onzin, omdat de veldnaam (de minisis mnemonic) maximaal 6 tekens lang is, bij oracle kan dit wel)
"field publikatietype=type publikatie" mag niet (spatie in de veldnaam)

Op dit moment werken aliassen alleen bij wq_fld en wq_lim.

Age Jan

voorbeeld van het gebruik van zelfbedachte parameters in cgiparm file

Hopelijk ter verduidelijking van een van de minder bekende mogelijkheden van WebQuery het volgende naar aanleiding van een vraag die ik vanmiddag kreeg.

Soms is het handig om een zelfbedachte parameter te introduceren in de cgiparm file. Een voorbeeld daarvan is de situatie waarin je een aantal parameters meegeeft aan een xslt. In dat geval moet je er rekening mee houden dat alle xslt-parameters met de zelfde suffix (of zonder) samen één parameter zijn voor WebQuery. Als je een aantal xslt-parameters hebt die altijd de zelfde waarde hebben, en één die bij een aantal suffixen andere waarden heeft, moet je dus alle

xslt-parameters voor elke suffix opnemen, dus als de basisset xslt-parameters er uit ziet als:

xslt-parameter aap='aap'
xslt-parameter xslt='&&xslt;'
xslt-parameter service='&&SERVICE;'
xslt-parameter andere-service='&&SCRIPT_NAME;/andereservice'

en er in de praktijk tien verschillende mogelijkheden zijn voor de waarde van andere-service, moet je in totaal 40 xslt-parameter regels opnemen, vier voor elke mogelijke waarde van andere-service.

Niet dus... er is een andere mogelijkheid, die er maar 14 nodig heeft. Daarvoor wijzig je de laatste regel in

xslt-parameter andere-service='&&SCRIPT_NAME;/&&andereservice;'

waarmee je aangeeft dat je niet de tekst "andereservice" maar de inhoud van de cgiparm parameter "andereservice" wilt gebruiken. Vervolgens definieer je die voor elke suffix, dus bijvoorbeeld

andereservice standaard-andereservice
andereservice_een alternatieve-andereservice
andereservice_twee nog-een-andere
andereservice_drie &&SERVICE;
hetkannnogcomplexer derde-waarde

etc. Als wq_sfx=een wordt meegegeven, krijgt xs xslt-parameter "andere-service" dus de waarde 'alternatieve-andereservice' (inclusief de enkele quotes).

Zoals je ziet, kan je ook de waarde van de meeste andere cgiparm parameters, zoals de naam van de gebruikte xslt ook meegeven als xslt-parameter.

Age Jan

Overbodige variabelen in xslt's

Bij het beantwoorden van een vraag van Marc viel mijn oog (in dit geval in sfx-button.xslt) op een sutiatie die ik de laatste tijd vaker tegenkwam, waarin eerst een variabel wordt gevuld, die dan vervolgens wordt afgedrukt, zoals in het volgende fragment:
<xsl:when test="artikel/auteur/corporatie/naam and artikel/auteur/corporatie/naam!=''"><xsl:variable name="must-urlencode-it">
<xsl:call-template name="urlencode">
<xsl:with-param select="artikel/auteur/corporatie/naam" name="string">
</xsl:call-template>
</xsl:variable>
<xsl:text>&aulast=</xsl:text>
<xsl:value-of select="$must-urlencode-it">
</xsl:when<>/xsl:value-of></xsl:with-param>
Dit fragment doet precies het zelfde als het volgende:
<xsl:when test="artikel/auteur/corporatie/naam and artikel/auteur/corporatie/naam!=''">
<xsl:text>&aulast=</xsl:text>
<xsl:call-template name="urlencode">
<\xsl:with-param select="artikel/auteur/corporatie/naam" name="string">
</xsl:call-template>
</xsl:when></xsl:with-param>
en omdat lege velden niet in de database mogen voorkomen kan het nog eenvoudiger:
<xsl:when test="artikel/auteur/corporatie/naam">
<xsl:text>&aulast=</xsl:text>
<\xsl:call-template name="urlencode">
<xsl:with-param select="artikel/auteur/corporatie/naam" name="string">
</xsl:call-template>
</xsl:when></xsl:with-param>
Vooral omdat het in dit geval gaat om de inhoud van een attribuut, waardoor xmlspy tientallen van dit soort constructies op één regel zet, zou ik iedereen willen vragen niet alleen te zoeken naar een constructie die werkt, maar ook even na te denken over de vraag of het niet eenvoudiger kan. Hier scheelt het m.i. behoorlijk in de leesbaarheid, en dus in de onderhoudbaarheid.
Age Jan