Re: [mylyn-integrators] Customizing task editor (parts) in Mylyn 3.0

["Steffen Pingel" <steffen.pingel@xxxxxxxxxxx>]

On Mon, Dec 1, 2008 at 9:28 PM, Tom Bryan (tombry) <tombry@xxxxxxxxx> wrote:

[..]

Do I just file bugs to request more
public access to things that I need?  I'd like to have a robust
connector that doesn't reimplement too much functionality that Mylyn
normally provides.

Yes, bugs are the best way to request API additions. It is a key design goal of the tasks framework to enable building of connectors without requiring integrators to duplicate existing functionality.

Let's just look at the attachment attributes first.  If I use the
TaskEditorAttachmentPart, it looks like I only get the few built-in
attributes in the attachment table.  I didn't see how to modify that
table, so I wrote my own part, table, content provider, and label
provider to show all of our attachments' attributes.

Is that the right approach in this case?  If I write my own attachment
part, I run into a lot of other problems.  For example, I lose the
standard Mylyn attachment table context menu since
TasksUiMenus.fillTaskAttachmentMenu is internal.  I could build my own
menu, but then I can't use the Mylyn actions since those actions are in
TaskUiMenus, too.  Even DownloadAttachmentJob is internal.  So, I
started with, "I want to display these three important custom attachment
attribute in the attachment table," and I ended up with "reimplement all
attachment actions from scratch."

In this case it is probably best to couple to internals, i.e. use TasksUiMenus to create the context menu. Please file a bug in this case that outlines your use-case so we can consider making the functionality available in the API.

We have committed to not breaking internals between minor releases. Meaning if you set a version constraint on Mylyn features (or plug-ins) in your manifest such as [3.0.0,3.1.0) users should not experience problems due to usage of internals. 

 

A second example involves our scores of attributes.  It's unwieldy to
show them all in TaskEditorAttributePart.  We split them up into
multiple parts that group related attributes.  That works well, but then
we have other problems.  I think that my AbstractTaskEditorPage needs to
override createParts() so that I can lay out my new attribute group
parts correctly.  I don't just need to suppress the part that's at
PATH_ATTRIBUTES.  I need to replace it with multiple parts that are
displayed in a multi-column layout.  No problem.  createParts() is
simple, and it's easy to write my own version.  But
AbstractTaskEditorPage.createParts(String,Composite,Collection) is
private (which seems to imply that I wasn't supposed to override
createParts()).  So, I would need to reimplement that method, too.  But
then my ISafeRunnable.run() method won't be able to call part.setPartId
from my package.  I have no idea why the ID isn't just part of the
AbstractTaskEditorPart constructor in the first place.  Gosh, where was
I?

The rationale behind not requiring an argument in the constructor of AbstractTaskEditorPart is to allow for a future extension point that would instantiate editor parts. The Eclipse extension point mechanism expects classes to have argument-less constructor.

I can see how the current API of AbstractTaskEditor makes it difficult to change the arangement of the sections. It should be a simple change to provide a protected method for creating a part from a part descriptor. Please file a bug for that. 

 

I really like how much Mylyn 3.0 pulls up into the framework.  It gives
the connector author a lot of functionality for free.  But, at least in
the task editor, it seems like the moment I try to make any
customization, I have to abandon almost everything that Mylyn provides
to a simpler connector.  I'm hoping that wasn't the intent!  :)

The old editor implementation exposed most of it's functionality in protected fields and methods. That made it very difficuilt to evolve the class or change anything about the editor. To allow for future changes of the editor we chose to hide more of the implementation details in internals and make the extensible parts more explicit.

The use-cases for extensibility that we took into account were mostly based on connector reference implementations and other Mylyn-based tools developed by Tasktop. I greatly appreciate your feedback and encourage you to file bugs to help us improve reusability and extensibility of the framework.

Steffen