Menu
▾
▴
extgraph-developer
|
From: Marco W. <in...@ca...> - 2005-03-07 10:43:26
|
Hi guys, It's been silent for a few days and I am wondering how things are going. I realize the code may very well be in the hands of Stefan and I'm contuing stuff on the multipoint links. If so, please let me know what to do with some of the new methods and fixes I've made. For now I still have a working copy and could simply send it by mail, yet I'd like to hear how things are going or where it's not going at all... ;) Marco. |
|
From: vrecion <pav...@sy...> - 2005-03-08 08:02:25
|
I have distributed packages to cvs. Check it, try it, pls. Let me know. Pavel -----Original Message----- From: ext...@li... [mailto:ext...@li...] On Behalf Of Marco Wobben Sent: Monday, March 07, 2005 11:43 AM To: ext...@li... Subject: [Extgraph-developer] Status Hi guys, It's been silent for a few days and I am wondering how things are going. I realize the code may very well be in the hands of Stefan and I'm contuing stuff on the multipoint links. If so, please let me know what to do with some of the new methods and fixes I've made. For now I still have a working copy and could simply send it by mail, yet I'd like to hear how things are going or where it's not going at all... ;) 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 |
|
From: Marco W. <in...@ca...> - 2005-03-08 10:06:56
|
Looks good to me. I've got additional work ready, do you wish to release this first as a new version and write some release info about the new stuff? Good enough to release: - HotTrack - InsertPoint, RemovePoint in the TGraphLink class - Fixes to BezierLink - TCurvedLink (Quadratic Bezier) Work in progress is: - TGraphProxy (for external objects identification and information. E.g. SVG or other repository formats, like I use in CaseTalk) Reference used for implementation is the design pattern book in our bookshelve. I think this will work very well and greatly extend the usability for the Graph library... ;) Ok, I'm a bit more enthousiastic because it may very well allow multiple proxies which enable it to work as a translation library as well (on the fly). More on the subject later. Regards, Marco. vrecion wrote: >I have distributed packages to cvs. >Check it, try it, pls. Let me know. >Pavel > >-----Original Message----- >From: ext...@li... >[mailto:ext...@li...] On Behalf Of Marco >Wobben >Sent: Monday, March 07, 2005 11:43 AM >To: ext...@li... >Subject: [Extgraph-developer] Status > >Hi guys, > >It's been silent for a few days and I am wondering how things are going. >I realize the code may very well be in the hands of Stefan and I'm >contuing stuff on the multipoint links. If so, please let me know what >to do with some of the new methods and fixes I've made. For now I still >have a working copy and could simply send it by mail, yet I'd like to >hear how things are going or where it's not going at all... ;) > >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 > > > > > |
|
From: vrecion <pav...@sy...> - 2005-03-08 10:16:40
|
Well, with the release I am not quite sure, while there is not ready important stuff - save/load of graphs. I do not quite understand TgraphProxy. Can you explain it a little? Thanx -----Original Message----- From: ext...@li... [mailto:ext...@li...] On Behalf Of Marco Wobben Sent: Tuesday, March 08, 2005 11:07 AM To: ext...@li... Subject: Re: [Extgraph-developer] Status Looks good to me. I've got additional work ready, do you wish to release this first as a new version and write some release info about the new stuff? Good enough to release: - HotTrack - InsertPoint, RemovePoint in the TGraphLink class - Fixes to BezierLink - TCurvedLink (Quadratic Bezier) Work in progress is: - TGraphProxy (for external objects identification and information. E.g. SVG or other repository formats, like I use in CaseTalk) Reference used for implementation is the design pattern book in our bookshelve. I think this will work very well and greatly extend the usability for the Graph library... ;) Ok, I'm a bit more enthousiastic because it may very well allow multiple proxies which enable it to work as a translation library as well (on the fly). More on the subject later. Regards, Marco. vrecion wrote: >I have distributed packages to cvs. >Check it, try it, pls. Let me know. >Pavel > >-----Original Message----- >From: ext...@li... >[mailto:ext...@li...] On Behalf Of Marco >Wobben >Sent: Monday, March 07, 2005 11:43 AM >To: ext...@li... >Subject: [Extgraph-developer] Status > >Hi guys, > >It's been silent for a few days and I am wondering how things are going. >I realize the code may very well be in the hands of Stefan and I'm >contuing stuff on the multipoint links. If so, please let me know what >to do with some of the new methods and fixes I've made. For now I still >have a working copy and could simply send it by mail, yet I'd like to >hear how things are going or where it's not going at all... ;) > >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 |
|
From: Marco W. <in...@ca...> - 2005-03-08 13:22:38
|
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. |
|
From: vrecion <pav...@sy...> - 2005-03-08 14:38:30
|
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
|
|
From: Marco W. <in...@ca...> - 2005-03-08 15:46:56
|
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
>
>
>
>
>
|
|
From: vrecion <pav...@sy...> - 2005-03-08 16:03:06
|
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
|
|
From: vrecion <pav...@sy...> - 2005-03-08 15:57:49
|
P.S. I would like to add just one comment. As we already discussed with Stefan earlier, we consider the state when extGraph development is "application driven" as healthy one and warmly welcomed. So, Marco, do not be afraid about support, your application needs has priority and should be taken into account. It is often difficult and time consuming to get to common understanding, but I am quite optimistic that we will find solutions together. IMHO, Marco, you are already benefitial to the project and your contribution is already significant. 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 |
|
From: Marco W. <in...@ca...> - 2005-03-09 14:09:48
|
Thanks, I will certainly continue the writing and coding. And I realize the common goals need time and much discussion. I already have such discussion with my collegues and email tends to be a bit more distracting and slower. We will continue emailing. ;) Have fun in the mountains. Marco. vrecion wrote: >P.S. >I would like to add just one comment. >As we already discussed with Stefan earlier, we consider the state when >extGraph development is "application driven" as healthy one and warmly >welcomed. > >So, Marco, do not be afraid about support, your application needs has >priority and should be taken into account. >It is often difficult and time consuming to get to common understanding, but >I am quite optimistic that we will find solutions together. >IMHO, Marco, you are already benefitial to the project and your contribution >is already significant. > >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 > > > > > |
Thanks for helping keep SourceForge clean.
X