Bugzilla – Full Text Bug Listing
| Summary: | [api] make ITaskListElement(s) adapt to tasks and containing repositories | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Mik Kersten <mik.kersten> |
| Component: | Mylyn | Assignee: | Mik Kersten <mik.kersten> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | ekuleshov, steffen.pingel, wmitsuda |
| Version: | unspecified | ||
| Target Milestone: | 2.0 | ||
| Hardware: | Other | ||
| OS: | other | ||
| Whiteboard: | |||
|
Description
Mik Kersten
Not clear yet if this makes sense to do. *** Bug 168376 has been marked as a duplicate of this bug. *** All the conversion code now makes this case pretty clear! Willian's notes from bug#165088 comment#54: There are many places inside source code where a selection is tested against many ifs to extract a common interface. Make them all adapters would simplify the code and make it more extensible, e.g., third-parties can expose a adapter for a proprietary object to some Mylar structure and get integrated "automagically". Hmm. Are you sure about adapting to tasks? That is a direct child of the task list element, so why not use inheritance? Summary is not specific enough. I meant Willian's case, and making AbstractQueryHit adapt to ITask, which may be better than the current getCorrespondingTask() idiom all over the place. I'm not quire sure about that because the method is more obvious than needing to know about the adapter. (In reply to comment #5) > Summary is not specific enough. I meant Willian's case, and making > AbstractQueryHit adapt to ITask, which may be better than the current > getCorrespondingTask() idiom all over the place. I'm not quire sure about that > because the method is more obvious than needing to know about the adapter. That is what I meant. It does not make sense to adapt query hits to tasks. Those are not really orthogonal things and don't have to be isolated from each other with performance hit cost. (In reply to comment #6) > That is what I meant. It does not make sense to adapt query hits to tasks. +1 The task hierarchy has changed to the point where this should not be required any longer. If use cases come up we can consider reopening post 2.0 to add any specific adapters since this would not affect binary compatibility (AbstractTaskContainer is a subtype of PlatfromObject, however, notably we do want to keep it de-coupled from TaskList and TaskRepositoryManager). I will update the Porting Guide with a class diagram to show the new hierarchy. |