Zojuist heb ik WebQuery 5.18 geactiveerd. Deze versie bevat twee langverwachte nieuwe query-parameters: wq_inf en wq_par.
De waarde die aan wq_inf wordt meegegeven wordt door WebQuery wel als query-element gezien, maar er wordt NIETS mee gedaan. Hij wordt dus ook niet doorgegeven aan de database-server. Maar omdat je in de cgiparm file nu ook alle query-elementen kunt benaderen kan je hem bijvoorbeeld wel doorgeven aan een xslt als xslt-parameterwaarde. Het voorbeeld:
xslt-parameter css='rsc/stijl/&&wq_inf1;_01.css'
Zorgt ervoor dat je via een dropdown box de kleur van de toegepaste standaardstijl kunt wijzigen. Dat geeft gelijk aan dat je eigenlijk verplicht bent om in de xslt te controleren of een op die manier doorgegeven variabele een geldige waarde heeft, want de eindgebruiker kan er in principe ALLES in zetten. Door volgnummers te gebruiken kan je meer dan één wq_inf waarde gebruiken. Het oneigenlijk gebruik van de gewone query-elementen om iets aan een xslt door te geven kan dus weggewerkt worden.
De waarde die aan wq_par wordt meegegeven moet er één zijn uit het volgende rijtje: "open", "(", "close", ")". Hiermee kan je prioriteiten aangeven binnen de query. Deze functionaliteit vervangt die van wq_lim. Voorlopig blijft wq_lim als invoer nog wel ondersteund; intern wordt het omgezet naar wq_par's.
Als gevolg van deze twee wijzigingen kan ik geen enkele reden meer bedenken om wq_qry nog te gebruiken, afgezien van de drie redenen waarom die mogelijkheid bestaat, namelijk het HANDMATIG geven van een complete query DOOR DE EINDGEBRUIKER, het weergeven van de query op het scherm en (voorlopig nog) het via een hidden field doorgeven van de "previous query" aan de volgende WebQuery call. Omdat de inhoud van het wq_qry element afhankelijk is van de achterliggende database-server zal elk ander gebruik van wq_qry op enig moment zonder nadere aankondiging tot problemen leiden.
Het probleem dat de impliciete OR (een veld gevolgd door eeen of meer "losse" wq_val elementen) niet van haakjes voorzien werd is eveneens opgelost.
De controle van de meegegeven query-elementen is iets aangepast, waardoor verkeerd geplaatste variabelen een betere foutmelding geven.
De debug-info wordt nu in xml gegeven (uiteraard alleen in debug-mode). Debug-mode is nu ook onafhankelijk van je ip-adres in te stellen met "wq_dbg=on" (zet dat svp NOOIT in een productie-pagina, want dan krijgt iedereen het te zien)
Met vriendelijke groet,
Age Jan Kuperus
Wageningen Digital Library
About me
- Peter van Boheemen
- I am head of application development at Wageningen UR Library, where we develop our own library application components if not available as open source or on the market.
2 comments:
Age Jan,
ik zie nog een groot voordeel van wq_qry: het is veel beter leesbaar dan het gebruik van wq_field, wq_val en wq_rel en wq_lim (1 wq_lim wordt nu blijkbaar vervangen door 2 wq_par 's en een wq_rel met waarde "AND"?) en het is veel minder gehannes met hidden formvelden om de zoekvraag in elkaar te zetten
, Frank
Frank,
Als je het als gebruiker bekijkt: ja, het is leesbaarder. Als je het als ontwikkelaar bekijkt, is dat wat mij betreft minder belangrijk dan de portabiliteit, niet alleen omdat we met verschillende databasesystemen werken, maar ook omdat er op dat gebied zoveel nieuwe ontwikkelingen zijn dat het zinvol kan zijn om nieuwe features in de database via WebQuery te gaan gebruiken. Bij de opzet van WebQuery is gepoogd zoveel mogelijk onafhankelijk te blijven van de onderliggende technologie. Wq_qry is daarop de belangrijkste uitzondering. De huidige oracle-implementatie maakt gebruik van een bepaald type indexen en de daarbij behorende query syntax. WebQuery maakt dit transparant voor de gebruiker, behalve bij wq_qry. Op het moment dat we besluiten geheel of gedeeltelijk over te stappen op nieuwere opties blijven alle "gewone" queries gelijk, maar moeten die met wq_qry wellicht gewijzigd worden. Vandaar mijn bezwaar tegen het gebruik ervan in formulieren en scripts.
Wq_fld, wq_val en wq_rel, en ook de nieuwe wq_par zijn optioneel:
wq_par=open&wq_fld=titel&wq_val=water&wq_rel=AND&wq_field=auteur&wq_val=jansen&wq_par=close&wq_rel=AND&wq_fld=jaar&wq_val=2004
Mag je ook schrijven als
titel=water&auteur=jansen&jaar=2004
dus in een form als 3 al dan niet zichtbare input velden met de namen titel, auteur en jaar
En
wq_fld=jaar&wq_val=1999&wq_rel=OR&wq_fld=jaar&wq_val=2002&wq_rel=OR&wq_fld=jaar&wq_val=2004
Mag je ook schrijven als
wq_fld=jaar&wq_val=1999&wq_val=2002&wq_val=2004
dus in een form als één hidden input field met de naam wq_val gevolgd door één select multiple="multiple" field met de naam wq_val
Of zelfs als
jaar=1999&wq_val=2002&wq_val=2004
dus in een form als één input veld met de naam jaar, gevolgd door twee input velden met de naam wq_val
(en dat zou ik ook doen waar het kan). Wat de handigste methode is, is afhankelijk van de opbouw van het formulier, en dankzij de nieuwe mogelijkheden (wq_par en wq_inf) kan je de constructie van de query nu volledig aan de browser overlaten.
, Age Jan
Post a Comment