Tickets :: Comment on [#7654] Search query parser for consistent search UI across all Horde apps

* Your Email Address
* Spam protection	Enter the letters below: ._.. ..__ . .__ \| \ /[__)\| [ __ _\|_ \/ \| \|___[_./
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.
Attachment
Watch this ticket

Saved Queries