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
2004-02-17
browsers en character sets
De bekende "browsers" gaan verwarrend en inconsequent om met charactersets. Als gevolg daarvan krijgt WebQuery problemen bij het invoeren van gegevens via formulieren. De theoretische oplossing is toevoeging van het attribuut accept-charset="iso-8859-1" aan alle formulierdefinities. Bij Mozilla en wellicht ook bij alle andere echte webbrowsers lost dit in één klap het probleem op. Bij de Internet Exploder van Microschoft natuurlijk niet, want die trekt zich van standaards nooit wat aan. Als het formulier op een html pagina staat (daarbij geeft Apache altijd aan dat het iso-8859-1 is), wordt ook iets dergelijks teruggegeven (zoals bekend met een paar niet-standaard tekens in de reeks 0x80-0x9f). Als het formulier op een pagina staat die door WebQuery of php in utf-8 gemaakt wordt, wordt echter utf-8 teruggestuurd, ongeacht of er accept-charset="iso-8859-1" in de fom tag staat of niet.
We hebben een aantal mogelijkheden om dit probleem aan te pakken:
We hebben een aantal mogelijkheden om dit probleem aan te pakken:
- IE uitbannen. Dit heeft mijn voorkeur maar is helaas niet realistisch in onze omgeving.
- Idem, maar alleen voor het invoeren en wijzigen. Onhandig voor de gebruiker.
- Altijd iso-8859-1 genereren in WebQuery en php scripts. Voor mij is dit de tweede keus, maar ik weet niet hoeveel extra werk dat oplevert.
- Een hidden field met een vaste naam en inhoud opnemen in elk formulier, waarmee we kunnen testen wat er teruggegeven wordt, en op basis waarvan we dan een extra vertaalslag inbouwen van utf-8 naar iso-8859-
1. Technisch haalbaar, maar niet-standaard, niet 100% zeker, en levert extra werk op. Wat mij betreft hooguit als noodoplossing.
Verwachten jullie problemen bij oplossing 3, of hebben jullie zelf een ander voorkeur? , Age Jan
2004-02-11
Het gebruik van exslt
Naar aanleiding van een vraag van Peter gistermiddag heb ik gisteravond een voorbeeld uitgewerkt van het gebruik van een van de belangrijkste xslt extensies. De essentie van de vraag was of het mogelijk is om een transformatie in twee (of meer) stappen uit te voeren binnen 1 xslt. Het antwoord daarop is in principe ja, maar er is een functie voor nodig die pas in xslt 2.0 standaard wordt. Veel xslt processoren hebben hem echter wel, of ze hebben er een workaround voor.Omdat de vraag voortkwam uit een discussie met Irene of er met een xslt een index op de rubriekendatabase gemaakt kon worden op basis van twee velden is het voorbeeld een xslt die een complete rubriekenlijst geeft, gevolgd door een engelstalige en een nederlandstalige index. De benodigde functionaliteit voor het aanroepen van de xslt extensies zit nog niet in WebQuery, en dat was meteen een aanleiding om te laten zien hoe je zoiets vanaf de linux command line kunt regelen. Voor degenen die meteen resultaten willen zien:xsltproc /DATA/www/WebQuery/xslt/rubriekenlijst-met-index.xslt "http://library.wur.nl/WebQuery/rubrik?wq_qry=isn%201%2f100&wq_fmt=xml&wq_sfx=XML"De xslt is voorzien van (hopelijk voldoende) commentaar. Toch wil ik er nog een aantal dingen aan toevoegen.Allereerst een motivatie voor het gebruik van de command line zoals hierboven. Op die manier kan je een dergelijke lijst ook heel eenvoudig automatisch elke dag/week/maand laten genereren als html file, door de output te redirecten en het geheel via een van de standaard schedulers (mijn voorkeur gaat uit naar cron, daar kom ik maandag op terug) op vaste momenten te laten uitvoeren. Vergelijkbaar met een job op de hp3000. Voor de hele rubrieken database duurt de query nu ongeveer 35 seconden, misschien net te lang om hem elke keer dat iemand hem nodig heeft uit te laten voeren. (het gaat hier uiteindelijk om een vervanging van een papieren versie; het zou me niet verbazen als hij meteen geprint wordt en dan pas een half jaar later weer eens opnieuw gevraagd wordt.Waarom niet cachen, zoals nu bij diverse toepassingen gebeurt? In de eerste plaats omdat ik vind dat dat een onjuist mechanisme is. Zoiets zou, als het al nodig is, binnen WebQuery, of nog beter, binnen Apache geregeld moeten worden, en niet binnen de toepassing. Daarnaast wordt steeds het zelfde wiel enigszins gewijzigd opnieuw uitgevonden, bewijst de huidige praktijk dat het (nog) niet probleemloos werkt, en de plaatsing van cache files op min of meer willekeurige plaatsen binnnen de website leidt tot security problemen.Dan nog een paar kanttekeningen bij de xslt. Ik heb geprobeerd daarin duidelijk te maken hoe je zo'n probleem (een basislijst met index(en)) kunt aanpakken, niet hoe je er een mooie lijst van maakt (de layout is zo simpel mogelijk).De basislijst maakt gebruik van het feit dat er in de database-uitvoer alleen tekst voorkomt binnen gewone velden en subvelden. Daardoor kan de volledige uitvoer ervan geregeld worden met het text() template. Dat drukt de naam van zijn parent node af, en zijn eigen inhoud. Zou er wel tekst (denk aan alleen maar een linefeed) op andere plaatsen kunnen voorkomen, dan wordt de uitvoer onleesbaar. "linefeed off" in de cgiparm file is dus een must voor deze oplossing.Nadat de basislijst gemaakt is komt de belangrijkste "truc". De variabele "index" wordt opgebouwd als result tree fragment. De templates die aangeroepen worden met mode="index" zorgen dus niet voor uitvoer in het eindresultaat, maar alleen voor het "vullen" van deze variabele.Ik heb gekozen voor een enkel template dat voor elke rubrieksnaam een keer wordt aangeroepen, met de taal en de code als parameters. Dat is m.i. de duidelijkste en meest declaratieve manier. Inplaats van de namen van alle velden had het match attribute ook "*" kunnen zijn, maar dit leek me duidelijker. Bij de aanroep is de taal als constante (dus als " ' e n ' " resp. " ' n l ' ") opgegeven, omdat die niet in de database voorkomt, maar afgeleid is uit de veldnaam.In het root template zou je na het aanmaken van de index deze kunnen controleren door de regeltoe te voegen. Daarmee zet je de volledige index als nodeset in de uitvoer. Dat komt dus (bijna) op het zelfde neer als wanneer de apply-templates die nu binnen de variabele-definitie staat daar buiten had gestaan.Helaas is dat ongeveer het enige dat je in xslt 1.0 met een result tree fragment, want dat is deze variable nu, kunt doen. Er is echter een extensie-functie die hem kan omzetten naar een node-set. Die gebruik ik in de rest van het root template tweemaal, een keer voor elke index. Omdat de attributen van het rubriek-element in de index-variabele alle gegevens bevat is de template die de uiteindelijk uitvoer ervan verzorgt nu heel eenvoudig.Ik hoop dat het bovenstaande weer wat vragen wegneemt. Het zal ongetwijfeld nieuwe oproepen, die hoor ik dan maandag wel. We zullen het dan, wat mij betreft, hebben over de manier waarop je regelmatig terugkerende zaken in unix kan regelen.Groeten,Age Jan
Subscribe to:
Posts (Atom)
