RE: [Extgraph-developer] The TGraphProxy Idea

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

OK.
I am interested. BTW Thursday I am going to mountains, to break a skis or
leg. :-)
So I will be on-line till tomorrow morning and then Monday.

Pavel

-----Original Message-----
From: ext...@li...
[mailto:ext...@li...] On Behalf Of Marco
Wobben
Sent: Tuesday, March 08, 2005 4:47 PM
To: ext...@li...
Subject: Re: [Extgraph-developer] The TGraphProxy Idea

I haven't got much time right now and want to come back on this. In the 
meanwhile let me just finish my proto and send you an email later this 
week (hopefully). I think just by refactoring some code I can show you 
what I have in mind. I do realize that you are abstracting the drawing 
stuff to the svg elements. However this doesn't abstract the data 
definition layer yet. If you continue this way, the SimpleGraph will do 
nothing but offer a bitmap for the svg-elements and you will end up with 
a new layer being implemented behind svg, since any data repository now 
has to create the svg elements and the drawing specifics...

The proxy will solve both since you'll be able to have multiple data 
storage fascilities which all take part in the grand-proces of drawing 
stuff...

Please let me show you later on...

Marco.

vrecion wrote:

>Lively discussion, isn't it? :-)
>That is what I like a lot in OS projects, really.
>I am afraid (but not sure) that there is misunderstanding of SVG idea.
>So excuse me if I will explain something that you are aware of already.
>There are two parts of SVG:
>- first is way, how data are stored in streams or files. Here SVG can be
one
>of the more formats.
>- second is the way of in memory objects representation
>
>I will discuss only the second part.
>We have several graph objects that has different graphical representations.
>They are nodes of same class:
>- TpolygonalNode
>- TrectangularNode
>- TroundRectangularNode
>- TroundRectangularNode
>- TellipticNode
>- TtriangularNode
>- TrhomboidalNode
>- TpentagonalNode
>
>There are also links, connecting nodes, but I will leave them aside for a
>while.
>
>Idea is to remove all nodes and replace them with SVG node that will have
>xml element where graphical shape is stored.
>Where are advantages of such approach?
>Imagine that you would need to add other shape for example cylinder for
>graphical representation of database. You will have to create another
object
>called say TcylinderNode and to implement it.
>In the case of SVG you will just supply different xml during node creation,
>without touching core classes.
>With svg node other shapes (like box with circles for firewall) are really
>easy to achieve.
>Some examples:
>Rectangular node is svg node with following xml:
><g id="1">
> <rect x="1" y="1" width="1198" height="398"/>
> <text x="20" y="20">This is rectangle</text>
></g>
>In fact svg graph object works with dom, so node shape can be created
>programatically either by parsing text or creating xml nodes like:
>SomeObject.SVG.AddChild(SVG.Document.createElement('rect').setAttribute('x'
,
>'1')); ...
>
>Another example:
><g id="2" width="300" height="300">
> <circle cx="150" cy="50" r="40" stroke="black" stroke-width="2"
>fill="bisque"/>
> <line x1="150" y1="90" x2="150" y2="200" stroke-width="2"/>
> <line x1="150" y1="200" x2="100" y2="300" stroke-width="2"/>
> <line x1="150" y1="200" x2="200" y2="300" stroke-width="2"/>
> <line x1="150" y1="120" x2="100" y2="200" stroke-width="2"/>
> <line x1="150" y1="120" x2="200" y2="200" stroke-width="2"/>
></svg>
>This xml processed by SVG node draws figure used as an Actor in UML
>diagrams.
>
>Equally straightforward is creation of specialized nodes. For example nodes
>storing data and processing them. Say that you need special node that will
>store and display integer value.
>You will the write something like this:
>
>TmyNode = class(TSVGNode)
>Private
> Function getMyInt:Integer;
> Procedure setMyInt(i:Integer);
>Property
> MyInt:Integer read getMyInt write setMyInt; 
>End;
>
>....
>Function TmyNode.getMyInt:Integer;
>Begin
> If SVG.FirstTag('data')<>nil
>  Then Result:=SVG.FirstTag('data').AsInteger //suppose that you decided to
>store your data in element with data tag
>  Else Result:=-1; // default value
>End;
>
>Procedure TmyNode.setMyInt(i:Integer);
>Begin
>If SVG.FirstTag('data')<>nil
>  Then SVG.FirstTag('data').AsInteger:=i 
>  Else SVG.AddChildElement('data').AsInteger:=i;  // create element and
fill
>value
>End;
>
>
>That is why there is svg code in current nodes, i.e. because of backward
>compatibility. But I agree that it makes code complex (I promise - will try
>to find another way to get both clener code and backward compatibility)
>
>Pavel
>
>-----Original Message-----
>From: ext...@li...
>[mailto:ext...@li...] On Behalf Of Marco
>Wobben
>Sent: Tuesday, March 08, 2005 2:22 PM
>To: ext...@li...
>Subject: [Extgraph-developer] The TGraphProxy Idea
>
>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.
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>  
>

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer