On Mon, Dec 1, 2008 at 9:28 PM, Tom Bryan (tombry) <[EMAIL PROTECTED]> 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
_______________________________________________ mylyn-integrators mailing list mylyn-integrators@eclipse.org https://dev.eclipse.org/mailman/listinfo/mylyn-integrators
