Op verzoek van Peter heb ik een mogelijkheid in WebQuery ingebouwd om de minisis-conversie te vereenvoudigen. Geen gedoe meer met aanroepen van de minisis-conversie template in je eigen templates. Als in een cgiparm-file een sterretje vóór de servernaam hp3000.library.wur.nl gezet wordt, doet WebQuery een automagische conversie, dat wil zeggen dat de conversie uitgevoerd wordt zonder dat je er verder iets voor hoeft te doen resp mag doen. Je xslt krijgt dan ALTIJD een geconverteerd bestand aangeboden. Zelfs met wq_sfx=XML wordt de conversie uitgevoerd.
Als voorbeeld heb ik de ejournals.xslt uit de testomgeving gekopieerd naar xxxejournals.xslt, en de wwwsrc.WebQuery cgiparm file naar wwwsrcc.WebQuery. Die kopieen werken op de nieuwe manier, als je tenminste ook nog de testversie (5.19) van WebQuery (dus bijvoorbeeld
http://test.library.wur.nl/test/WebQuery/wwwsrcc?ti=science&wq_max=10&wq_fmt=xml ) gebruikt.
Age Jan
2004-08-23
2004-08-17
WebQuery Request cookie problemen
Vanmorgen bleek bij het uietzoeken van een support call dat het WebQueryRequest cookie, dat gezet wordt als iemand een database probeert te benaderen zonder op de juiste manier te zijn ingelogd, soms ongewenste bij-effecten heeft.
Het werkt als volgt: als een niet-toegankelijke pagina wordt benaderd wordt het WebQueryRequest cookie meegegeven, waarin staat wat er niet lukte. Meestal wordt dan een login pagina getoond. Na het inloggen wordt dan de mogelijkheid gegeven om de oorspronkelijke pagina opnieuw op te roepen, of wordt dat automatisch gedaan.
Het probleem is, dat als, zoals op de desktop, geen login pagina getoond wordt (maar de "my library" login knop), het WebQueryRequest cookie nog een tijd blijft bestaan. Wordt binnen die tijd een (niet aan de vorige pagina gerelateerde) login pagina getoond, bijvoorbeeld die van wurpubrd, dan zal, omdat het cookie voorrang heeft boven de eventueel in die pagina aanwezige C- en D velden, gecontroleerd worden of de voorgaande pagina (in het vorbeeldgeval een profielu pagina) nu wel toegankelijk is. Als dit niet het geval is verschijnt een foutmelding, die aangeeft dat een voor de gebruiker nu niet relevante pagina niet toegankelijk is.
Omdat WebQuery niet kan weten of het WebQueryRequest cookie door zo'n constructie zinloos geworden is, is op dit moment de enige oplossing om eerst expliciet uit te loggen en dan opnieuw in te loggen (uitloggen verwijdert het cookie). Een betere oplossing is m.i. om in de desktop op een andere manier te controleren of iemand is ingelogd. Daarvoor zou het in 5.17 geintroduceerde WebQueryUser cookie gebruikt kunnen worden, of een ander soort who-am-i uitvoer.
Wat is jullie mening hierover?
, Age Jan
Het werkt als volgt: als een niet-toegankelijke pagina wordt benaderd wordt het WebQueryRequest cookie meegegeven, waarin staat wat er niet lukte. Meestal wordt dan een login pagina getoond. Na het inloggen wordt dan de mogelijkheid gegeven om de oorspronkelijke pagina opnieuw op te roepen, of wordt dat automatisch gedaan.
Het probleem is, dat als, zoals op de desktop, geen login pagina getoond wordt (maar de "my library" login knop), het WebQueryRequest cookie nog een tijd blijft bestaan. Wordt binnen die tijd een (niet aan de vorige pagina gerelateerde) login pagina getoond, bijvoorbeeld die van wurpubrd, dan zal, omdat het cookie voorrang heeft boven de eventueel in die pagina aanwezige C- en D velden, gecontroleerd worden of de voorgaande pagina (in het vorbeeldgeval een profielu pagina) nu wel toegankelijk is. Als dit niet het geval is verschijnt een foutmelding, die aangeeft dat een voor de gebruiker nu niet relevante pagina niet toegankelijk is.
Omdat WebQuery niet kan weten of het WebQueryRequest cookie door zo'n constructie zinloos geworden is, is op dit moment de enige oplossing om eerst expliciet uit te loggen en dan opnieuw in te loggen (uitloggen verwijdert het cookie). Een betere oplossing is m.i. om in de desktop op een andere manier te controleren of iemand is ingelogd. Daarvoor zou het in 5.17 geintroduceerde WebQueryUser cookie gebruikt kunnen worden, of een ander soort who-am-i uitvoer.
Wat is jullie mening hierover?
, Age Jan
WebQuery 5.18
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
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
Subscribe to:
Posts (Atom)
