Community
Participate
Working Groups
In the reviews project we would like to add our own review sections to some types of tasks/bugs as well as hiding some sections(which don't make much sense in a review). Currently we are stuck with extending each implementation of task editor page to perform these operations, which is not very maintainable and extensible. As this feature could also be useful for other projects (e.g. changeset section for the scm project) we would like some api for covering this use case.
I wonder if we could have the idea of a conflicting section id, similar to how we have conflicting editor ids in the page factory.
Created attachment 173984 [details] api proposal After experimenting with adding conflicting ids to the taskEditorPageContribution, it still lacked a mechanism to remove or add section to only some specific tasks, so I've extended the taskEditorPageContribution with an partAdvisor element.
Created attachment 176427 [details] api proposal, which includes some basic lifecycle callbacks from the task editor page
Thanks for the patch, Kilian. This is a good first pass and I like the idea of adding an advisor class that can customize or configure a task editor page. I am concerned though that the proposed implementation mixes UI concerns (configuring editor parts) with hooks for task submission. I would prefer if we kept these concerns separately to also support task submission outside of the task editor. I think the first step would be to resolve bug 280234 to create an API for managing task editor parts. I am thinking that the page would create an initial list of parts which could be modified by each advisor. The hooks for task submission should probably be registered through a separate extension point that is tight to SubmitTaskJob rather than the editor. Some more general remarks about the API design: * Any class that is intended to be implemented by clients should be an abstract class rather than an interface to allow future enhancements, i.e. ITaskEditorPartDescriptorAdvisor should be refactored to TaskEditorPageAdvisor. * Event handler methods should have an event object as a parameter that provides all state related to the event. Again, this allows future enhancements without breaking binary backwards compatibility, e.g. public abstract class TaskEditorPageAdvisor { initializePage(TaskEditorPageEvent event); } public class TaskEditorPageEvent { AbstractTaskEditorPage page; TaskEditorPartDescriptorList part; } What do you think?
Kilian, do we still need to do this for 3.5 based on the latest UI design discussion around reviews?
No I don't think we actually use this at the moment. Adding a changeset section could be useful for versions (task-changeset mapping), but that also works with another task editor page.
Thanks. I'll take it off the milestone since it's pretty overloaded already. It could make sense to put change sets on a separate page but we also have an extension point to contribute sections to the task editor if needed.
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
