Community
Participate
Working Groups
If users try to extend the task data classes, deserialization can fail due to class load failure.
To further the discussion I quote a bit from http://www.codeguru.com/java/tij/tij0127.shtml [...] Here is the output from three different runs: Duplication via serialization: 3400 Milliseconds Duplication via cloning: 110 Milliseconds Duplication via serialization: 3410 Milliseconds Duplication via cloning: 110 Milliseconds Duplication via serialization: 3520 Milliseconds Duplication via cloning: 110 Milliseconds [...] So I think that your bug report should somehow identify the problem properly and prefer a proper deep-cloneable implementation, if only for performance reasons. To loose the subclassing will kill the current work on the generic SQL connector: bug 184532: [connector] Generic SQL connector https://bugs.eclipse.org/bugs/show_bug.cgi?id=184532 It will also probably severely hinder connector implementors. There are just too many open bug reports with the [connector] keyword in it! Also see bug 206698: [api] provide mechanism for adding AttributeContainer to RepositoryTaskData https://bugs.eclipse.org/bugs/show_bug.cgi?id=206698 which works against this
These classes are very flexible attribute containers, most of the setter/getter methods are just convenience methods hiding the repository key. If these are to become final you lose the flexibility of the attribute container scheme. So it is no longer extensible. I think the solution is to refactor the deepCopy operation inside TaskDataManager$ObjectCloner.deepCopy so it no longer needs serialization. If you go for making final, then these classes need a fully orthogonal set of getters/setters. For example TaskComment misses the following: - getAuthor(String) - getTaskId() - setAuthorName(String) - setCreated(String) - setTaskId(String) - setText(String) And AbstractTask misses the following: - getEstimatedTimeHours see bug 222196:[api]renameAbstractTask.getEstimateTimeHoursto getEstimatedTimeHours If you have some attributes with convenience getters setters and others without, you become less flexible.
I found a work around for the work on the SQL connector bug 184532 but still feel the setters/getters should be orthogonal.
Thanks for all your input on this Maarten. We will certainly take all this into account when refactoring the offline support for 3.0.
I am currently leaning towards turning TaskData into a persistence API and moving connector specific type conversion and attribute mapping into AbstractAttributeMapper. Task comments and attachments will be decoupled from TaskData and provide getters and setters for the attributes that are part of the common schema. Cloning of TaskData will most likely not rely on serialization in the future for creating clones but use a more robust implementation that copies attribute values.
(In reply to comment #5) > I am currently leaning towards turning TaskData into a persistence API and > moving connector specific type conversion and attribute mapping into > AbstractAttributeMapper. Task comments and attachments will be decoupled from > TaskData and provide getters and setters for the attributes that are part of > the common schema. I was thinking about proposing that the editor be made more flexible by declarative attribute naming: The editor is now a container for attributes with currently two subcontainers: comments and attachments, the attribute keys now contain dot notation, for example: - task.common.comment.text The editor is made up of a number of sections: - main - attributes - attachments (sublist) with new attachment section - description - comments (sublist) with new comment section - actions - people Wouldn't it make it a lot easier for connector developers if this scheme is extended to incorporate some more information, like section to duisplay, type, rw or ro, etc which would then be parsed by the taskeditor builder: attribute task.comment.screenshot.image.ro would mean that it is a read-only image to be displayed in the comment section attribute task.main.producticon.image.ro would mean that it is a read only product icon to be displayed in the main header attribute task.attribute.duedate.date.rw would mean that it is an editable date to be displayed in the attribute section attribute task.people.qa.person.rw would mean that it is an editable person field to be displayed in the people section attribute task.action.closed.option would mean that it is an option field to be displayed in the action section The attributes would give the proper title in the AttributeFactory. This would make the editor a more intelligent displayer of the enclosed attributes. > Cloning of TaskData will most likely not rely on serialization in the future > for creating clones but use a more robust implementation that copies attribute > values. That may give performance benefits as well ;-)
We are in the process of extending the meta data scheme for attributes. It is likely that there will be a new class in Mylyn 3.0, e.g.: TaskAttributeProperties { boolean showInAttributesSection() boolean showInToolTip() String getLabel() } In the current API the type of an attributes is available be invoking AbstractAttributeMapper.getType(RepositoryTaskAttribute). It's an interesting to encode these properties in the attribute key but I would prefer to make this more obvious and explicit in the Java code. Concerning containers we were discussing to make every attribute a container to enable client to store data structures other than attachments and operations that are complex.
(In reply to comment #7) > It's an interesting > to encode these properties in the attribute key but I would prefer to make this > more obvious and explicit in the Java code. I understand, but I'm working on the generic SQL connector, where I intend to end up with something where you only ever define the mapping from the SQL database to some property and never touch the java code. Is there a plan to separate the rendering engine that draws the form editor? If so I can hook in one with this feature.
Yes, you can either provide your own editor implementation or extend AttributeEditorFactory to control how attributes are rendered / edited.
TaskData, TaskAttribute and related classes are now final to avoid confusion about the intended extensibility.
