Bug 154687 - [gmfgraph] Support for scalable Polygons
Summary: [gmfgraph] Support for scalable Polygons
Status: RESOLVED FIXED
Alias: None
Product: GMF-Tooling (ARCHIVED)
Classification: Modeling
Component: Core (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Michael Golubev CLA
QA Contact:
URL:
Whiteboard:
Keywords: contributed
Depends on:
Blocks:
 
Reported: 2006-08-22 08:47 EDT by Michael Golubev CLA
Modified: 2010-07-19 22:19 EDT (History)
0 users

See Also:


Attachments
Fixes the subj (128.93 KB, patch)
2006-08-24 10:58 EDT, Michael Golubev CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Golubev CLA 2006-08-22 08:47:37 EDT
Actually all polygons generated by gmfgraph have fixed size that depends only on absolute coordinates of gmfgraph.Polygon's template points. There was a lot of requests in the news group to optionally support scalable polygons that always fit the available bounds.

Say, to express UML2 activity diagram decision node, someone wants to define rhomb figure that will be automatically scaled to fit the diagram node bounds. Actually gmfgraph generator is limited to produce only rhombs with fixed size. 

Expected: introduce boolean attribute scalable (default = false for backward compatibility) into the gmfgraph.Polygon class. In case if it set to true generated figure should extend ad hoc base class ScalablePolygon that automatically transforms the point list before painting to fit the node bounds. 

It would be helpfull to include this base implementation into one of the runtime plugins. However, until it is not yet included, both diagram and gmfgraph generators may generate the fixed class contents into the same package as all editparts/figures. This way the class will be visible for all generated figures using only hardocded simple (not fully-qualified) name.
Comment 1 Michael Golubev CLA 2006-08-23 07:57:51 EDT
After discussion with Alexander Shatalin we have decided to try another approach, that is, always generate ScalablePolygon code during gmfgraph codegenration. This way no changes in the gmfgen are required, and no hardcoded names are used.

To support generation in the both contexts (gmfgen and standalone gmfgraph plugin), and avoid compilaton issues with the class extends inner class or name clashes in case if each compilation unit will have 2 top-level classes, it should be implemented as follows:

In case if scalable polygon is top-level in FigureGallery, then the ad hoc code that supports scalability should be manually added into the top-level class as follows: 

public class DecisionFigure extends Shape {
     //begin ad hoc
     PointList myPoints;
     private void scale() {...}
     public void addPoint(..) {...}
     //end ad hoc
     //begin common gmfgraph generator
     public DecisionFigure(){
         ...
         createContents();
     }

     private void createContents() {...}
     ///end common
}

In case if scalable polygon happens to be deeper inside hierarchy, it should be generated as inner class in the figure class as follows:

public class MyRectangle extends RectangleFigure {
     public class ScalablePolygon {
         //begin ad hoc
         PointList myPoints;
         private void scale() {...}
         public void addPoint(..) {...}
         //end ad hoc
     }

     //begin common gmfgraph generator
     public MyRectangle(){
         ...
         createContents();
     }

     private void createContents() {...}
     ///end common
}
Comment 2 Michael Golubev CLA 2006-08-24 10:58:52 EDT
Created attachment 48589 [details]
Fixes the subj
Comment 3 Artem Tikhomirov CLA 2006-08-24 11:35:29 EDT
reviewed, refactored and committed.
Comment 4 Artem Tikhomirov CLA 2006-08-24 11:35:51 EDT
... and closed
Comment 5 Eclipse Webmaster CLA 2010-07-19 22:19:59 EDT
[GMF Restructure] Bug 319140 : product GMF and component
Generation was the original product and component for this bug