Re: [pmf-dev] Wazaabi design

[Olivier Moïses <olivier@xxxxxxxxxxxxxxxxxxx>]

Hi Hallvard,

I am, at the moment, working on writing documentation about wazaabi (and the wazaabi's proposal too :-D).
There is additional information here : http://wazaabi.org/documentation/technical-description/the-engines/a-simple-example.

Regarding the EditPartHelper, you're right. The main problem is that the engine respects the model. If we want to use the SWT implementation, there is two separate layers in the model : core & swt and then two separate engines : core & swt.
The core engine is also the base code for swing implementation (a working proof of concept at the moment) and future ones (eSWT, GWT ...).
SWT metamodel inherits from core metamodel and uses multiple inheritance, the EditPartHelpers are here for simulating this multiple inheritance. Another point : in the previous versions of wazaabi, the EditPart classes (and several others) were provided by GEF bundle, months ago I re-integrated this classes (accordingly to EPL) into wazaabi core plugin, so, now this classes could be changed, may be it could be other way to (re)implement that.
However, I am more interested by the automatic generation of boilerplate code instead of trying to remove it (could be more efficient in term of time consumed).
Moving the getEditPartHelper () to a more abstract level could be also an option but before to do that we should validate that other concrete (future) implementations will not be polluted. 

PlantUML looks great, I will, as soon as possible try to use it !!

Olivier

2010/4/27 Hallvard Trætteberg <hal@xxxxxxxxxxx>

Olivier,

I'm trying to get familiar with Wazaabi's design, both model and implementation. It seems that for each concrete widget EClass, e.g. Label, there is an EditPart/EditPartImpl, EditPartHelper and View. Could you explain the role of each of these? I think some sequence diagrams explaining how the collaborate would be great. I've just discovered the PlantUML project and Eclipse plugin, that makes the creation of such diagrams as documentation fairly easy. Just add a textual representation of the diagram using a simple syntax to a comment in the Java code, and view the diagram in the PlantUML view.

>From looking at the code, I get the impression that there's a lot of boilerplate code, with potential to simplify things. E.g. each edit part has a helper, and most (if not all) delegate to it in methods like the following two.

       public void notifyChanged(Notification notification) {
               if (isActive()) {
                       editPartHelper.notifyChanged(notification);
                       super.notifyChanged(notification);
               }
       }

       protected void refreshVisuals() {
               editPartHelper.refreshVisuals();
               super.refreshVisuals();
       }

Since the field for the edit part helper is declared fairly low in the subclass hierarchy, you also have to have these methods in each of these subclasses. If you introduced an abstract method getEditPartHelper() in an abstract edit part impl. class, you could also move these methods up into an abstract, to avoid duplicate code.

If I'm going to help you with TabFolder and Tab widgets, I will need a better understanding of the design.

Hallvard
_______________________________________________
pmf-dev mailing list
pmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pmf-dev