[Extgraph-developer] The TGraphProxy Idea

[Marco W. <in...@ca...>]

Hi guys,

I've joined the SimpleGraph developers group to be able to implement
features in the Graph library for a specific graph library purpose. I
need it to display information from a repository and not have it any
other way. The link between stored information and the visual
representation requires identification and information to be portable to
and from the graphs. For this sollution I think a TGraphProxy is
required. Reading up on several design patterns, I've came to the
conclusion that this pattern is the way to go for this issue.

This would solve another issue I commented on earlier, SVG
implementation within the main source and baseclasses. I'm still working
on a first draft and hope to get it working sometime soon. Implementing
such a sollution has a personal high priority. Extracting technically
specific code implementation (like SVG, but also in my case other
standards) would bring back the focus where it should be. Focus on SVG
in the SVG code and focus for TExtGraph in the graph code. (And needless
to say I can focus on other standards without complaining or having to
worry too much about IFDEFs and other code implementations I do not
require.)

So what about this so called TGraphProxy? The answer I'm given is
partially based upon my finding in the current SVG code and partially on
my 'not implemented yet' needs. What I can see in the Graph classes are
the following items:

- GraphObjects are identified.
- GraphObjects have properties.
- GraphObjects are added, removed and updated.

The internals of TGraph(Objects) perform all these actions, and specific
descendant classes add functionality for a specific display feature. My
idea is to have the above list of functionality published to an external
component, a Proxy. A TExtGraph would have a publised property which is
to be a component link to a TCustomGraphProxy. Whenever a object is
inserted (removed or updated) it should trigger a method on the Proxy.
Off course the proxy would do this both ways so that a technical
implementation (e.g. SVG) would add an element it would at this as a
proper TGraphObject to the appropriate TExtGraph instance.

Synchronization options can be set at the Proxy. In case of SVG, one
would probably want the XmlDom to be a reflection off the Graph, meaning
that it must be fully synchronized. Other sollutions may be implemented,
having a one way sync for instance would allow a repository of objects
being available to be drawn.

Here my description stops, since I need to implement this in a
prototype, but I'm convinced this could very well work and allow other
developers to add new technical layers very easily. Additionally,
perhaps needless to say, multiple proxies could allow object translation
on the fly. Having both Graph, SVG and other standards simultaniously...

So far my deep thoughs and ambition.

Marco.