I just proposed an alternate solution to the "long
advanced search" issue in JIRA -- I'm copying it here for convenience:
Here's another possible approach to the problem that reduces
reliance on saved searches at the cost of adding an extra redirect to the
advanced search process.
1.) Advanced search screen always uses POST, and includes a special hidden
field that flags searches that are POSTed from it.
2.) Search processing code detects the "POSTed Advanced Search" flag
and converts all POST fields (minus the special hidden flag) into GET
parameters, building up a new URL.
3.) We can now measure the length of the GET version of the advanced search. If
it is short enough, we can just redirect there. If it is too long, we can save
the search object and redirect to the saved link.
Bottom line is that we perform a POST and then intermediate code turns it into
a GET. That's an extra step that may slow things down slightly, but I don't
think it's likely to be noticed. We only resort to saved searches in what I
expect to be a very rare case, and we have completely stable (not tied to
database), copyable URLs the rest of the time.
Does this make sense? I can put together a patch file as a demo if you like.
From: Greg Pendlebury
Sent: Wednesday, October 28, 2009 10:33 PM
Subject: [VuFind-Tech] Long urls from advanced search
added a comment here that requires some feedback:
copy/pasted below for convenience, but please respond in JIRA (or send to me
and I’ll add your comment to JIRA). I’m trying to be a good boy and put more in
the top of my head there are three related issues here:
1) Facets (RESOLVED)... since facets no longer are called via AJAX.
2) Solr query (RESOLVED). Solr.php appears to handle POST fine, and I've just
switched the search object to default submitting POST queries to solr.
3) Long urls for the user getting from the advanced screen to the results list.
A) My tests this morning with three decent search groups resulted in a 385
character URL, translating into 6,000+ on the solr url (which isn't the issue).
I wonder whether this is really an issue with a 2,000 (practical) character
B) IF we still need to resolve point 3 I've considered the advanced screen
'reserving' a search table row and redirecting via url to edit that search ID.
Then submitting via post with an id in the URL (action attribute of the form).
The search is still copy/pastable that way, which was really the only
detraction from a simple POST conversion of the form. BUT for that complication
there are still limits. We would have to default to saving searches for the url
to persist by default, and we would have to default to 'public' saved searches
to allow the url to be sent to another person.
Services Officer (Systems Team)
of Academic Information Services
of Southern Queensland
This email (including any attached files) is confidential
and is for the intended recipient(s) only. If you received this email by
mistake, please, as a courtesy, tell the sender, then delete this email.
The views and opinions are the originator's and do not necessarily reflect
those of the University of Southern Queensland. Although all reasonable
precautions were taken to ensure that this email contained no viruses at the
time it was sent we accept no liability for any losses arising from its
The University of Southern Queensland is a registered provider of education
with the Australian Government (CRICOS Institution Code No's. QLD 00244B / NSW