Community
Participate
Working Groups
The current task editor find implementation in the sandbox creates source viewer controls as it searches for text. To ensure good performance it should operate on the data model rather than the user interface and only create description/comment viewers as needed.
could u give some hints on how to initiate the implementation? I have two ideas after some lookups (operating find on the data model): 1) add the find concerns to AbstractAttributeEditor (e.g. AbstractAttributeEditor.findInAttribute(..)) which has TaskAttribute and we start by matching TaskAttribute.getValue() with expected regular expression. 2) add the concerns to TaskAttribute (e.g. TaskAttribute.findByKeywords(..)). One of the drawback of searching the data model is that it might be difficult to match the location in the model with the location in the widget (e.g. we need to highlight the find results in the source viewer). Any thoughts? You might have better ideas than I do :)
To scope this first cut of a model-based search implementation it should be sufficient to limit it to the task editor and worry about a more generalized task search later (bug 165391, bug 191522). Could you list the requirements for a search API in more detail? Taking the Firefox search as an example I can come up with this: List<SearchResult> findAll(SearchCriteria) SearchResult findNext(SearchCriteria, SearchResult) SearchResult findPrevious(SearchCriteria, SearchResult) void highlight(List<SearchResult>) SearchCriteria could encapsulate the search mode, e.g. if it is case sensitive, regular expression based etc. It would be great if you could take a look at the existing APIs in Eclipse, e.g. for text editor search, to get an idea how to design this. Using attribute editors could work well since they provide a link between the data model and the user interface and can implement highlighting properly. I don't think a list of attribute editors is currently available in the API but the attribute editor factory would be a good a place to manage these. This might require changes to the part implementations to create attribute editors more eagerly. This should be okay since they are designed to be lightweight as long as the controls are not realized.
I follow up with more descriptions (fix me if anything is inappropriate): * AbstractAttributeEditor - void highlight(List<SearchResult>) - IRegion modelRange2WidgetRange(IRegion) - IModelFindManager getModelFindManager() * IModleFindManager [using AbstractAttributeEditor.getModelFindManager()] - List<SearchResult> findAll(SearchCriteria) - SearchResult findNext(SearchCriteria, SearchResult) - SearchResult findPrevious(SearchCriteria, SearchResult) * SearchResult - IRegion getRegion() - String getFindString() * SearchCriteria - SearchCriteria (startModelOffset, findString, isForwardSearch, isCaseSensitive, isWholeWord, isRegExSearch) - we might not need that much options - getter & setter The only thing I am not sure is how to highlight the results in a proper Text/TextViewer control, we might also need to a setText(..) method in AbstractAttributeEditor.
I did some initial implementations. The following problems are observed: 1) The UI & and model cannot be easily connected, e.g. AbstractAttributeEditor knows nothing of "part", its difficult to only create description/comment viewers as needed. 2) AbstractAttributeEditors are lazily created as a widget, so its impossible to find the model before building the widget, that means we have to create the widget first. My conclusion is AbstractAttributeEditor might not be a good place to host the "find"
Thanks for summarizing your findings. I agree that this will require further work on the framework side such as a mapping between the data model and the attribute editors and ways to programmatically construct and display editor controls. There is some overlap with other bugs such as bug 242430 (editor validation) or bug 166123 (navigate to comment) as well which should be considered when designing a generic solution. An initial implementation prototype could be specific to the comment part to get a better sense for the abstraction. I'll lower the priority for now. I think it's best to focus on completing the other open tasks first and then we can revisit this task.
(In reply to comment #5) > Thanks for summarizing your findings. I agree that this will require further > work on the framework side such as a mapping between the data model and the > attribute editors and ways to programmatically construct and display editor > controls. There is some overlap with other bugs such as bug 242430 (editor > validation) or bug 166123 (navigate to comment) as well which should be > considered when designing a generic solution. > > An initial implementation prototype could be specific to the comment part to > get a better sense for the abstraction. I'll lower the priority for now. I > think it's best to focus on completing the other open tasks first and then we > can revisit this task. > Can start iterating this bug?
Sure. Hack away :). Note, that I'll probably move the comment grouping from the sandbox to main sometime this week.
We ended up treating this and its parent as one task. *** This bug has been marked as a duplicate of bug 134165 ***
