Tickets :: Comment on [#4928] Combine "Tickets which are" and "Type" selects in Search form

* Your Email Address
* Spam protection	Enter the letters below: .__. ..___. __ . . [__] \| \| / `\ / \| \|\__\| \| \__. \/
Comment	>>> I will provide a unified diff. > >> Great, thank you. > > > > Unified diff attached. > > > >>> Before doing so, I'd like to finish the changes. My question is: how > >>> can I render a table of multienums in a single row? > >> You're going to need to write a custom form renderer. It doesn't have > >> to be fancy, just override creation of a separate table row for each > >> input. (I'll get into more detail if you need, but there are some > >> around in whups - queries - and other apps.) > > > > I never figured out how to write the custom form renderer (owing to > having essentially zero free time), so I didn't take this beyond the > screen shot you see attached to this ticket. I've also not > bulletproofed this code, as I got it to the level of "good enough" > for us. It seems to work fine, though. > > > >> I wasn't able to entirely follow the diff since it wasn't against > >> HEAD, but yeah, that's likely fine. Feel free to add those unit > >> tests. :) > > > > It's been a while since I've looked at this code, but let me give it > an explanatory whirl. I modified three files: 1 in Horde proper > (Horde/Form.php) and 2 in Whups (search.php & Forms/Search.php). > > > > In Horde, the change was simply to add a utility method named > Horde_Form_Type::getValues() to recover the (presumably) private > $_values member variable. Call me OO-obsessive. > > > > In Whups Forms/Search.php, I changed the queue selection from > drop-down ("enum") to a multi-drop-down ("multi-enum"), and I added a > message declaring what would happen if you didn't select any of the > multi-enum values (this was for usability's sake). I then needed to > remove the "Tickets which are" and "Types" variables and replace them > with a loop over all ticket types, adding multi-enum variables for > each ticket type. > > > > In Whups search.php, I made the biggest changes. These were largely > cleanup operations, to aid in my development as I waded through the > code: > > 1. The code to determine the URL needed to re-run the query was moved > in to a function named getSearchReplayURL(). > > 2. The code to save a search (if logged in) was simplified by using a > helper method called getNameForCriterion(): this method takes a > criterion name (such as "queue", "summary", etc), inspects the > submitted values, and then returns a human-understandable string > describing the submitted values. Owing to the changes mentioned in > Ticket 4897, this may no longer be needed. > > 3. The code to "munge a query into acceptability" was moved into a > method called mungeInfo(). > > > > These should be relatively easy to patch into HEAD. Let me know if > you need more details. Thanks!
Attachment
Watch this ticket

Saved Queries