Re: [Extgraph-developer] The TGraphProxy Idea

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

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
>
>
>
>  
>