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.

[ Show » ]

Demian Katz added a comment - 29/Oct/09 09:14 AM - edited 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.


- Demian

 

From: Greg Pendlebury [mailto:Greg.Pendlebury@usq.edu.au]
Sent: Wednesday, October 28, 2009 10:33 PM
To: vufind-tech@lists.sourceforge.net
Subject: [VuFind-Tech] Long urls from advanced search

 

FYI

 

I’ve added a comment here that requires some feedback:

http://vufind.org/jira/browse/VUFIND-5

 

I’ve 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 JIRA J

 

 

“Off 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. Discussed below.

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 limit.

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.

 

Ta,

 

Greg Pendlebury

Electronic Services Officer (Systems Team)

Division of Academic Information Services

University of Southern Queensland

Phone: +61 7 4631 1501

Fax: +61 7 4631 1841

 

 


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 receipt.

The University of Southern Queensland is a registered provider of education with the Australian Government (CRICOS Institution Code No's. QLD 00244B / NSW 02225M)