So far I have been able to get attributes from TaskData. While this
works, it is slow and its clear that TaskData isn't intended for
frequent read access to TaskAttributes, so I'd like to find a more
efficient way, that fits with how Mylyn is designed.
- TaskData looks like it is intended to back task editing pages, not
every task show in a grid of 100s of tasks.
- TaskData is loaded from XML every time you ask for it
Yes, that is correct. One approach to avoid frequent disc access would be to
load the required task data objects once, extract the neccessary fields and
cache them in your own data structure.
AbstractTask has an attribute Map, would it a sensible approach be to
put the few values I need to read often there - hoisting them up from
TaskData ?
- If so please advise on how to keep this view of attribute values in-sync
- What listeners and calbacks should I use to faithfully track the real
attribute values
- Idealy I'd like to see saved values (outgoing changes)
Please keep in mind that ITask objects are kept in memory and are designed to
provide the attributes required by the task list. While the attribute map can
be used to store additional attributes and might work well in this case is
intended to be used by connectors only. This is discussed on this bug report
in more detail:
199818: [api] arbitrary attributes in AbstractTask
https://bugs.eclipse.org/bugs/show_bug.cgi?id=199818
I would recommend to implement your own data structury that caches the
relevant information for your view. To keep the data in sync you can register
an ITaskDataManagerListener using TaskDataManager.addListener(). The listener
is notified when the task data is updated from the repository. It is
currently not fired when task data is saved in the editor but that is
something that we certainly could add.
I am not sure that there is a way to implement this without using internals at
the moment. That said I would be interested in improving the API to support
efficient access to (parts of) task data. Please feel free to file a bug
report that describes your use case and requirements so we can discuss
changes to the API further.
Steffen