Login | Register
My pages Projects Community openCollabNet

Discussions > dev > [long] RE: [gef-dev] Refactoring GEF Figs for better extensibilit y

gef
Discussion topic

Back to topic list

[long] RE: [gef-dev] Refactoring GEF Figs for better extensibilit y

Reply

Author "Smith, Brian" <SmithBL at mail dot medicine dot uiowa dot edu>
Full name "Smith, Brian" <SmithBL at mail dot medicine dot uiowa dot edu>
Date 2000-05-29 22:22:41 PDT
Message In my previous post I mentioned that I had an idea about how to handle
FigNode and FigEdge in PGML (and SVG). First, I'll point some things that
might be improved upon that aren't affected by PGML/SVG. I'm posting this
(very long) article here to get feedback from the people involved in this
project, and to better my understanding of GEF so that I can use it in my
real applications. Are these ideas crazy? Are the changes suggested too
much? Is there any reason why it would be bad to do these things?

1. The semantics of ungrouping a FigNode are unclear. Should the FigNode
object disappear (and result in information loss)? Should it live on
(somewhere)? As I mentioned before, I think that FigNode should not have
FigGroup as a superclass, but rather should contain a FigNode as an
attribute. One benefit of this: contained figs could be ungrouped while
still maintaining important information about their relationships.

2. FigLine and its subclasses do a good job of representing styled paths (in
the vector-graphics sense) that would be useful for figures that aren't
connected to any model. For example, it is useful to have a rectilinear
polylines and dotted lines that don't have anything to do with a connected
graph. In fact, there is already a polyline class that can be rectilinear
(FigPoly). It seems best to put all of the graphical features of FigLine
(and its subclasses) in the FigPoly hierarchy. Then FigEdge could contain a
FigPoly and be made much simpler (and their wouldn't be a dual inheritance
hierarchy with FigEdge and FigPoly):

====================​====================​==
- Fig
   +--> FigLine (can be styled; e.g., dashed)
   +--> FigPoly (can be styled like FigLine)
         +--> FigRectiline
         +--> FigSpline
         +--> FigInk
   +--> FigEllipse (FigCircle is really an ellipse)
   +--> FigImage
   +--> FigRect (can be styled like FigLine)
          +--> FigRRect (ditto)
   +--> FigGroup (contains a set of Figs)
   +--> FigEdge (contains a FigPoly)
   +--> FigNode (contains a FigGroup)
====================​====================​==

Of course, if that was done, then the purpose of FigEdge and FigNode would
be to map the Figs to the objects in the model and vice-versa. They don't
really need to be Figs to do that:

====================​===============
- Fig
   +--> FigLine
        ...
   +--> FigGroup
- ModelFigMapping
   +--> EdgeFigMapping (was FigEdge)
   +--> NodeFigMapping (was FigNode)
   +--> PortFigMapping (is this needed?)
====================​================

and actually, the classes in the FigPoly hierarchy might be better off it
the Strategy pattern is used to get the path:

====================​=================
- Fig
   +--> FigLine
   +--> FigEllipse
   +--> FigPoly (has a PolyStrategy)
   +--> FigGroup
- PolyStrategy
   +--> RectilinearPolyStrategy
   +--> SplinePolyStrategy
   +--> LinePolyStrategy
- ModelFigMapping
   +--> EdgeFigMapping
   +--> NodeFigMapping
   +--> PortFigMapping
====================​=================

I think a lot is gained by doing this. First, it doesn't matter who is
mapping the figs to the graph model elements; it could be the figs
themselves, the diagram, the graph model, or something else completely.
There is a clear separation of responsibilities: The figure classes draw
figures, the model classes model graphs, and the mapping classes map between
figures and graph elements. Programs that just need some simple vector
graphics editing (not based on an explicit graph model) could use the Figs,
and programs that don't want to draw graphs could use just the GraphModels.
I think this makes GEF much more valuable to the Java community.

It would also be easy to add new figures types that can be bound to new
graph element types. For example, somebody ambitious might make a FigShape
that lets GEF use Java2D Shapes, or a lot of the Fig hierarchy could even
implement the Java2D Shape interfaces. Then those shape types could be
assigned dynamically to various graph element types. The reason I mention
Java2D is that there will likely be complete mappings between SVG and Java2D
in the near future, and GEF could leverage one of those mappings. Also, I
think the best way to support SVG is to create Java2D shapes from the SVG
elements, then wrap those shapes into GEF Figs (and then go the other
direction for saving). Unfortunately, this is very difficult to do if The
Node/Edge/Port concept is embedded into the Figs.

Anyway, it's getting late, and this is a very long post. Please let me know
what you think. I am thinking about doing some of this for the GEF SVG
proposal, but I feel like it might be too much for people to accept. Even if
people feel like it is the wrong way to go for that RFP, I would like to dig
in and start working on this outside of it if people like the ideas.

- Brian

« Previous message in topic | 1 of 1 | Next message in topic »

Messages

Show all messages in topic

[long] RE: [gef-dev] Refactoring GEF Figs for better extensibilit y "Smith, Brian" <SmithBL at mail dot medicine dot uiowa dot edu> "Smith, Brian" <SmithBL at mail dot medicine dot uiowa dot edu> 2000-05-29 22:22:41 PDT
Messages per page: