6.0.0-git
2019-01-21

[#7654] Search query parser for consistent search UI across all Horde apps
Summary Search query parser for consistent search UI across all Horde apps
Queue Horde Framework Packages
Queue Version HEAD
Type Enhancement
State Assigned
Priority 1. Low
Owners chuck (at) horde (dot) org
Requester chuck (at) horde (dot) org
Created 2008-11-07 (3727 days ago)
Due
Updated 2009-09-07 (3423 days ago)
Assigned
Resolved
Milestone
Patch No

History
2008-11-07 03:25:49 Chuck Hagenbuch Comment #1
Type ⇒ Enhancement
State ⇒ Assigned
Priority ⇒ 1. Low
Summary ⇒ Search query parser for consistent search UI across all Horde apps
Queue ⇒ Horde Framework Packages
Assigned to Chuck Hagenbuch
Milestone ⇒
Patch ⇒ No
Reply to this comment
I want to write a framework package - current working name 
Horde_Search_StringParser - that will parse searches entered into a 
single text input and do something useful with them, that is 
consistent across all Horde apps. We should then put a search bar at 
the top right of all apps possible, that uses this syntax. The bars 
that are already there in Whups and Wicked (others?) should be 
extended to use the new syntax; Wicked already does a decent job of 
running a useful search based on any text that's entered, but Whups 
just takes ticket ids and could be a *lot* more useful with this.



Gmail has a good description of the syntax and rules that I think I 
want to follow almost exactly, with the exception of detecting a 
search that's only an integer and flagging it differently (at least 
where relevant for Whups, etc.).



http://mail.google.com/support/bin/answer.py?answer=7190



And my original notes before finding the gmail doc (this is no longer 
the full intent here but I'm including it for completeness, content, 
and thought process):



class that all app can use for standardized parsing of text into 
search criteria (not SQL; could be then turned into SQL, though).



should be internationalized like horde_date_parser and 
horde_support_numerizer will be.



rules:

- all numeric: it's an id

- simple string: search the default text field

- text with colons: search named fields



examples:

1234 - returns type id, value 1234

foo - returns type default, value foo

foo: bar, baz: qux - returns type array (?), value array('foo' => 
'bar', 'baz' => 'qux')

foo: bar, baz, qux - returns type array, value array('foo' => 'bar, baz, qux')



Incorporate the same rules, implemented in javascript, to 
QuickFinder.js (maybe rename that too?), and allow for naming columns 
so that the criteria searches work. Might be too complicated to pull 
columns out of tables when searching, though - pre-caching probably 
won't work anymore at least.

Saved Queries