[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Substitution Parameters in CQL
Hi Matthew:
Interesting idea but doesn't this suffer from the same defect that my initial idea of arbitrary string fragmentation [1] had, namely that empty values will upset the querystring and render it non-CQL.
And if we bring JavaScript into the picture then a) we don't need the template as such, and b) we still haven't resolved connecting *any* form (with multiple inputs) to an SRU server (expecting one query input) because we have an N:1 impedance mismatch on query parameters.
We should note that JavaScript is a client facility over which the user may or may not have control.
Tony
[1] My initial idea was to break a query string into consecutive numbered fragments which could then be recomposed by sequencing the fragments, i.e.
query = q1 + q2 + q3 + ...
-----Original Message-----
From: Matthew Dovey [mailto:m.dovey@jisc.ac.uk]
Sent: Thu 12/23/2010 9:13 PM
To: Hammond, Tony; 'Denenberg, Ray'; 'OASIS SWS TC'
Subject: Substitution Parameters in CQL
I felt that there was a nore elegant solution to the forms issue, and I've realised what I'd been vaguely thinking of - allowing substitution parameters in CQL.
Basicallly, the idea is that you can put a placeholder in the CQL query itself whose value is take from a url parameter.
I'm going to use {} to indicate these parameters in my examples, but we may need a better syntax to avoid ambiguity.
So the query
author = {qt1}
would be interpreted as author = whatever the value of the qt1 parameter is.
A form with two input boxes allowing an author and title search would have a hidden field for the query parameter with the value
author = {qt1} and title = {qt2}
A more generic query would be
{qi1} {qr1} {qt1} {qb1} {qi2} {qr2} {qt2}
I have used Tony's convention above but there is no particular need to. I could use
author = {author} and title = {title}
This would clearly only work for forms with a fixed know number of search terms. However since in order to have a form which allowed the user to arbitrarily add search terms would require javascript anyway, this isn't an issue.
The idea needs work to turn this into a robust specification (either a new CQL feature or an extension to CQL) but I wanted feedback as to the approach.
Matthew
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]