Most of the classes are likely to be extended, but almost all variables are private

[GoogleCodeExporter]

What steps will reproduce the problem?
Most of the classes like Graph, Node, Edge or all of the visual classes are
candidates to be subclassed but almost all variables inside these classes
are private.  

What is the expected output? What do you see instead?
Would be great if you changed the variables the subclasses are likely to
use(most of the hash tables(Dictionary)) to protected.

Original issue reported on code.google.com by andreas....@gmail.com on 8 Apr 2008 at 10:05

[GoogleCodeExporter]

And all of the basic classes should be subclassed from EventDispatcher class to 
be
able  to dispatch custom events.

Original comment by andreas....@gmail.com on 8 Apr 2008 at 6:34

[GoogleCodeExporter]

I second this, I had to make a slightly custom version of VisualGraph and ended 
up
having to fork my own GraphLayout.swc because I couldn't get to any of the 
internal
properties when I inherited.  Please make most things in the classes protected!

Original comment by gvilc...@gmail.com on 22 Apr 2008 at 1:02

[GoogleCodeExporter]

Hmm ok, I guess these are valid suggestions.
Could you please specify a list of classes you would like to
inherit fully?

What about the event dispatcher ancestor? Where do you need to dispatch
events from and what for?

I am happy to add it, but I would like to understand better the reasons
and see some examples where it is useful.

Since multiple inheritance does not work for good reasons, I want to
be careful what to inherit in the base classes.

Original comment by spo...@gmail.com on 18 May 2008 at 5:51

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

All of your default classes are likely to be inherited: Graph, Node, Edge,
VisualGraph, VisualNode and VisualEdge. A good example why you need to inherit 
the
Graph class is a different method to initialize the graph(currently only 
GraphML like
XML is supported).   The node class can also get additional properties. I can 
save
them within the "data" object of the node but it is not the best solution to add
properties to the data object if they definitely belong to the graph structure 
itself.
But the biggest problems I have had with your library is that you do not use 
events
at all. A good solution is that when you add/remove a node/edge, your Graph 
fires an
event. Within the VisualGraph you add an EventListener to the graph instance and
visually reflect the changes to the structure everytime your graph structure 
fires
events. It is basically the main idea behind the "Model View Controller" 
paradigm.
Then it will be possible to have multiple presentations of the same Graph(here
model)(like a big Graph and a small preview in the corner) without the need to
manually synchronize them. The same is true for mouse and keyboard gestures. 
Every
time you select/click/double click/move an node/edge, VisualGraph should fire an
event. You react on these events within your VisualGraph by default gesture 
event
listeners(double click changes the root, click and drag moves the node/edge), 
but be
sure to allow the user to disable the defaults and define other gesture 
reactions.
But to be able to use it you have to be able to dispatch events. It is not 
necessary
that all of your classes inherit from event dispatcher, although almost all flex
classes do that, but be sure to implement the IEventDispatcher interface. 
I am using your library in my master thesis. Currently I am writing the text 
and have
not much time to code. But next month I am going to code a lot and I can send 
you
some samples of the classes I change and/or inherit.

Original comment by andreas....@gmail.com on 20 May 2008 at 12:32