Community
Participate
Working Groups
Mylar provides search wizard for Bugzilla issue tracking system. It would make sense to generalize this feature and allow other connectors (e.g. Jira) to plug into this, so it would be generic "Issue Search" tab.
It seems we need a provider-specific search panel that could be plugged in into this seach tab.
Bumping the priority of this since Trac needs it.
BTW, I refactored Jira query wizard to have single page, so it should make easy to integrate it as well.
Excellent. In that case I will use that as the driver and Steffen can replicate for Trac.
It should not be complicated to extract the code that creates the controls for the query page. It would be helpful to have an abstract implementation for ISearchQuery and ISearchResult though.
Rob, I just explored this and it's related to your fixes the the repository search page and generalization of repository settings. Here's how it should work: * Top of the page allows any repository to be selected * Connector provides a search page for that repository * Diaolog settings are saved per repository (not sure if the concrete page or the common page saves them) * Search results view is probably generic enough alread If you end up generalizing a search mechanism keep in mind that we want it to work headless via tasks.core, so put the classes in there. Please schedule this for right after 0.6.1 goes out.
Starting on this today but away 3 - 8th August.
Update: Okay, so I had a look at this today. So far I've extracted a AbstractRepositoryQueryPage which extends WizardPage and implements ISearchPage. This makes it possible to use the same custom query page in the query wizard and in the search page (when the custom query extends AbstractRepositoryQueryPage). Connector specific 'search' action can be implemented by overriding performAction(). There is now a RepositoryQueryPage that has a repository selection at the top (as per comment#6) and selection thereof displays the query page gathered from connector.getQueryPage(...). At preset each repository has its own page but ideally this will eventually be one per connector type with just the attributes being updated if a repository of the same type is chosen. I've done a little testing with the trac custom query page and it seems to all work well (with some layout issues of course). I'll undo these changes though and you can implement performAction() etc as you see fit Steffen. This said, I haven't yet looked into what is required for generic search/results so that is on my plate for Friday. If anybody has any thoughts/comments/alarms related to this architecture just shout! :)
Sounds good. I have opened bug 153539 for the Trac implementation. I'll look into that as soon as this bug is resolved
Committed to HEAD what I've got so far. Changes since comment#8 include extraction of the query results view into tasks.ui.search. To implement search you should be able to extend AbstractRepositorySearchQuery and override the run method (See BugzillaSearchQuery, or PluginSearchQuery for examples).
Created attachment 47809 [details] Relayout controls on repository change Here is a small patch that should properly layout the dialog when the repository is changed. Rob, please have a look at the patch I attached to bug 153539. It has generic search classes (based on Bugzilla) in trac.ui.search which should probably be moved to tasks.core. If we changed the signature of AbstractRepositoryConnector.performQuery() to something like IStatus performQuery(AbstractRepositoryQuery query, IProgressMonitor monitor, IQueryHitCollector resultCollector); connectors would basically have to implement that method only for query and search support. BTW, we should think about removing some of the borders on the Bugzilla query page to make it look more like the other search tabs.
(In reply to comment #11) > BTW, we should think about removing some of the borders on the Bugzilla query > page to make it look more like the other search tabs. I wanted to cleanup bugzilla query page and make it work with swt designer, but Mik asked me to wait till common search functionality is complete.
Thanks Steffen, I've applied your patches and will look into the changes you suggest regarding AbstractRepositoryConnector.performQuery(...). Eugene, just give us a bit more time to stabilize search then you can take a crack at the ui clean up. It is risky business though as BugzillaSearchPage code is old, finicky and not very pretty. ;) P.S. There is a known regression with these new changes: Opening hits does a refreshAndOpenTaskListElement which creates local tasks (rather than opening the hit as is). I'm looking into a solution.
Steffen, I believe Mik will be splitting AbstractRepositoryConnector into core and ui soon. My thinking is that once that is done we'll move those generic search classes into tasks.core and then see if RepositorySearchQuery can be pulled from ui as well.
The regression noted in comment#13 has been resolved as part of bug#152132.
I'm in the midst of the changes suggested in comment#11 with an eye toward core/ui separation (bug#155279). I'll make the api changes and update the various connectors to the point of operational, then the component owners can take it from there. Sound good?
> I'll make the api changes and update the various connectors to the point of > operational, then the component owners can take it from there. Sound good? Yes, go ahead :).
Okay I've committed the first pass at this. All tests pass and I've done a bit of manual testing but please keep an eye out for regressions. There is of course room for improvement in the internal implementation of performQuery for each connector now that the collector is being passed in. Now we can start to do as Steffen suggested and try to make exclusive use of this new method for all query/search and see what needs to be changed or added. :)
Marking fixed. Separating search into core and ui on bug#155279.
Created attachment 49097 [details] mylar/context/zip
