[mylar-dev] Architectural question...

[Boris Pruessmann <boris@xxxxxxxxxxxxxx>]

Everyone,

I've got a probably simple question regarding the Mylar architecture.  
If this already has been discussed in the past, feel free to point
me to some documentation as I don't want to restart a discussions  
that has already been completed.

I think you've all done a great job in providing a framework that's  
pretty easy to hook into and I greatly appreciate that. On the other
hand, I've already run into several situations where I wanted to do  
things differently and that couldn't easily be achieved, at least
not without patching the Mylar source code. And all of those things  
just boil down to one issue: the use of abstract classes instead
of interfaces (in contrast to abstract classes in conjunction with  
interfaces)

So my question is this: is there any specific reason why you chose  
this approach? I just want to give you one specific example that's
troubling me though I could probably come up with others:

I want to write a page for the task editor that has a completely  
different look and feel than pages based on  
AbstractRepositoryTaskEditor.
I can return something different (based on IEditorPart) out of my  
task editor factory. Unfortunately that would not behave as first-class
citizen because TaskEditor includes code fragments that only execute  
against AbstractRepositoryTaskEditor based classes. An interface
in addition to the abstract class would solve this.

Anyone? ;-)

Cheers,
Boris