From: Demian K. <dem...@vi...> - 2009-10-20 15:00:27
|
I think I've fixed the Javascript errors on the advanced search screen -- just moved the code to load advanced.js up above the first call to the functions defined in that file. Let me know if you still see any issues. I've created VUFIND-139 in JIRA to track the broken advanced limiters -- feel free to add some comments on there about the need for "all" options (or make it a separate issue if you prefer). Location seems like a site-specific limiter -- places with only one location won't want to show it, but it's definitely valuable for others. Seems to argue toward configurable limiters similar to our current configurable facets. Maybe another issue to add to JIRA if it's not already in there somewhere. - Demian From: Osullivan L. [mailto:L.O...@sw...] Sent: Tuesday, October 20, 2009 9:32 AM To: Demian Katz; Greg Pendlebury Cc: vuf...@li... Subject: RE: [VuFind-General] [VuFind-Tech] SearchObject update Perhaps we can have basic, advanced and super-duper-advanced search links? ;) I've showed it to some guys here and they are positively drooling over its power! I bet Greg has suffered a few AND, OR, NOT headaches during its design. Hiding some functionality until it is selected seems like a logical step. Some other suggestions / observations (some of which will be in other JIRAs): Can you add a remove Search Field button too? The default trunk still has an empty language / format box. An All option for Call Number, Language, Format and Illustrations is still missing. York University has added Location to the advanced search options. That may be a welcome addition here? Cheers, Luke ________________________________ From: Demian Katz [mailto:dem...@vi...] Sent: 20 October 2009 14:19 To: Osullivan L.; Greg Pendlebury Cc: vuf...@li... Subject: RE: [VuFind-General] [VuFind-Tech] SearchObject update Thanks for helping with the testing! Regarding the advanced search complexity, in an off-list conversation with Greg, I suggested that it might help to hide all the group-related controls until the user actually goes ahead and adds a second group. He mentioned similar suggestions from users on his end. I think something like this would go a long way toward making the interface easier to understand for the casual user -- hopefully it'll be added before too long (and I'm willing to help with the implementation if necessary). - Demian From: Osullivan L. [mailto:L.O...@sw...] Sent: Tuesday, October 20, 2009 9:12 AM To: Greg Pendlebury Cc: vuf...@li... Subject: Re: [VuFind-General] [VuFind-Tech] SearchObject update Hi Greg, I've just installed a version of the Trunk which I'm not going to tinker with and have managed to look at your updates in all their glory. They work superbly! The advanced search will be really powerful though I think it may confuse some users (I'm thinking lowest common denominator here!). I'm not too bothered about this as they can always just use the basic search and facets. With regards to the error I mentioned, it still shows up on Firebug on Firefox using Ubuntu. Functionality however is not impaired. It is because you are calling the addGroup function at the end of step 1 before it has been defined in step 2 (link to advanced.js). I have commented out the var new_group = addGroup(); addSearch(new_group); addSearch(new_group); section of part 1 and all is fine. The Saved Search feature is also really useful. Might I suggest it (or a link to it) be added to the Your Account Section? Kind Regards, Luke ________________________________ From: Greg Pendlebury [mailto:Gre...@us...] Sent: 20 October 2009 03:39 To: Greg Pendlebury; Osullivan L. Cc: 'vuf...@li...' Subject: RE: [VuFind-Tech] SearchObject update Hmmm, can you still reproduce this issue (2) with a fresh install from trunk Luke? I've tried 4 browser now but can't cause this error with the base setup. Perhaps it's a local modification conflicting. 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 From: Greg Pendlebury Sent: Thursday, 15 October 2009 9:03 AM To: 'Osullivan L.' Cc: vuf...@li... Subject: RE: [VuFind-Tech] SearchObject update Thanks Luke: 1) Yes, the patch is large enough that even minor deviations from trunk will cause conflicts. 2) The order of the 3 scripts tags is significant because the first one needs to use smarty translates to define values, the second one needs to use those values inside it's functions and the last one needs to make use of the functions, but also smarty foreach/if blocks. I'll do some cross browser testing to make sure the order is ok for everyone. Strangely the fix you suggest breaks for me in Firefox 3.5 so I'll have to take a deeper look. 3) Yes, I haven't touched the underlying search fields yet. 4) I'm not sure what you mean. That a row gets inserted but the 'search_object' column blob is empty? 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 From: Osullivan L. [mailto:L.O...@sw...] Sent: Wednesday, 14 October 2009 9:40 PM To: Greg Pendlebury Cc: vuf...@li... Subject: RE: [VuFind-Tech] SearchObject update Hi Greg, You've been busy! I've tried to install your patch but hit a few snags. It's likely that they are due to some local tinkering by myself but I thought I'd share them just in case anyone else has similar issues: 1) The patching of Search/History.php and web/lang/en.ini failed so I had to do them manually 2) In Search/Advanced I get a javascript error - addGroup is not defined - If I move the reference to advanced.js to the top of advanced.tpl, this error is resolved 3) When I perform an advanced search, Solr returns an undefined field "all" error 4) The Entries in the search table are empty apart from created 5) As a consequence of the above, the Save Search option does not work As I say, it probably something I've done which means the patch doesn't work. I can see how the functionality will work however and I think it will be a great addition to VuFind. Kind Regards, Luke ________________________________ From: Greg Pendlebury [mailto:Gre...@us...] Sent: 14 October 2009 06:05 To: vuf...@li... Subject: [VuFind-Tech] SearchObject update I've put a bit of work into this over the last week to try and progress closer to submitting to the trunk. Attached is a patch against r1606 of the trunk that includes all current work. Some basic bullet point notes are below. As always, any feedback from testing is greatly appreciated. I was about 2-300 patches away from trunk in the usq branch, so I rebuilt the laptop codebase today and discovered I had missed maybe one or two of those patches. I'm going to recreate the usq branch as a copy of current trunk to make patch generation easier again for a while. Database * The search history is now kept in a modified 'Search' table. Added 'saved', 'session_id' and 'search_object' columns and removed 'lookfor', 'type' and 'limitto'. * 'last_used' is now indexed in the 'Session' table. * 'session_id' is now an index in the 'Search' table. * In passing... I noticed that you get a key constraint on the 'User' table using the Demo driver if you don't use the same password each time (because it lets any password log in). Has anyone experienced problems with users that change their passwords via other auth methods? * Schema and sql file both updated. Saved Searches * Searches now go into the 'Search' table instead of a cookie for the search history. The session object checks for searches (that aren't saved) from this session and removes them as part of it's destructor. Anecdotal (but not comprehensive) testing of session garbage collection suggests this works too. * The 'saved' flag can be turned on from the top of a results list or the from the search history screen. Users are prompted to login if they aren't already. * Saved searches store the 'user_id' in the table and are retrievable from anywhere the user logs in... currently with no expiry. * Management of this area bears consideration... expiry dates? Limits on the number of saved searches? * Possibility of orphan searches evading the garbage collector. 1) User creates the search. 2) User saves the search. 3) Garbage collector for the session fires, but ignores the search because it is saved. 4) User 'un-saves' the search and it return to their 'un-saved' search history. 5) Search is now an orphan the garbage collector won't find because it's session has already been cleaned. Easy solution would be to delete entirely instead of 'un-save'. * Saved searches can be passed into the results page and retrieved. No facility for making public yet (shouldn't be too hard). Results screen ensures users can only view searches from their session or user_id. * Saved searches can be handed to the advanced search screen for editing. Login Followups * Some initial work in improving the current code allowing for followup actions on a login screen. * This is currently quite rough and could be overhauled in general. * Used at the moment to challenge the user for a login before saving their search. Advanced Search * Completely overhauled (has been demo'd previously) to replace 'Search Within' functionality. * Allows editing of old searches. * Old searches will retain the filters they had applied by default. New interface elements allow the filters to be removed. * Still needs <noscript> functionality. * Still needs old index fields to be updated post-dismax changes. Layout Search Form * The basic search form is hidden on the advanced search screen. * 'Search Within' is gone, in it's place is a checkbox to retain the currently active filter(s) when starting a new search. Default to 'checked'. * The results screen of an advanced search does not display a basic search form. Instead it displays links to start new searches or edit the current advanced search. Spell checking * The search object now processes the spelling suggestions provided by results. When the array is retrieved it will provide urls for using the new terms as both replacements and expansions on the current search. * Replacements are a simple find/replace on the suggested term, default usage and what the interface currently presents as the link underlying the term on screen. * Expansion allow you to add the new term into the search as an OR where the old term is found. Currently it's the '(E)' beside each term. Our staff here are arguing over an icon (as always). * I've added them into the interface on the assumption that people who don't want them will just disable them. * My dev laptop returns multiple suggestions. Testing the patch today against a fresh install it was only returning one, so I need to look at this. Probably index related. * Still have concerns over 'onlyMorePopular' but I don't think there's a solution short of modifying solr/lucene. * Using a recent solr nightly was required to get the most out of spell checking. Language File * I've started using more meaningful indexes in the language file so when reading the language file you would know when/why the string is being used. * It's an idea and an example, please let me know if you greatly object to this change. Search Object * Fixes all url mangling issues (that I've looked for) relating to facets, pages, sorting etc on the results screen. * My old RSS fix is currently in place. I haven't yet looked at Andrew's recent work on this to integrate. * Still doesn't integrate with statistics, this is the last area in Results.php to change (from memory). 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) ________________________________ 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) |