Menu
▾
▴
RE: [Extgraph-developer] Architecture talk (aka Proxy)
|
From: Pavel V. <cz3...@ti...> - 2005-03-15 17:49:33
|
OK Marco send me a code or make changes in cvs. My plans are: - to create something like xml proxy object. Reason is loosen dependency on XML Partner implementation and to get rid of changed XPDom. - I have created a mess in cvs repository - mainly due to my not so steep= learning curve :-) . - New demo application to test and show svg stuff. Pavel >-- P=F9vodn=ED zpr=E1va -- >From: Marco Wobben <in...@ca...> >To: ext...@li... >Subject: [Extgraph-developer] Architecture talk (aka Proxy) >Date: Tue, 15 Mar 2005 13:08:01 +0100 > > >Ok guys, > >I've had a change of mind. The previously mentioned Proxy component is >not really a proxy but more of a Bridge. Thinking this through more and >more doesn't reduce the work at hand. I've more or less re-factored the >svg into a egSvgBridge, egSvgNodes and implemented a very(!) rough >TExtGraphBridge. At this moment it is nothing more than extracting the >svg stuff and pushing it into a seperate unit. The two-way communication= > >between the xml dom tree and the ExtGraph is not complete. Since I don't= > >have the xml components I won't get it to work as easily as I would like= >to. > >So, to divide the workload I would like Parvel to have a look and see if= > >he can repair the damage I've done to it. My future thoughts on the >Bridge technology goes beyond the svg implementation. It would even >allow multiple ExtGraphs with a single Bridge. To really make this work,= > >more internals on node and link manipulation need to be extracted from >the ExtGraph class. More logic needs to go into the ExtGraphBridge >class. Not really difficult, yet it requires a lot of work and re-factor= ing. > >I'm thinking to far beyond to pull this off in a single increment. The >idea is to go towards the following architecture in several code increme= nts: > >ExtGraph -> CustomBridge > | > /-----------\ > ExtBridge SvgBridge > > > GraphObject > | > ^ > /---------\ > GraphNode GraphLink > | \ > ^ \ > /---------\ \--------\ >RectangleNode SvgNode \ \ > BezierLink CurvedLink > > >ExtGraph is to be responsible for the drawing and gui of the graph >itself. It will still control all nodes and links, yet allows the >ExtBridge to intercept all communication on the collection of nodes and >links it displays. Instead of having eventhandlers on the ExtGraph >itself these will be moved towards (or extended on) the ExtBridge. The >other way around the Bridge will contain methods to insert nodes and >links into the ExtGraph. Different bridge classes, like SvgBridge, will >service other methods which allow a different language (svg) to be used >to manipulate the nodes and links on the ExtGraph. > >I do hope this makes sence to you all. I can barely keep up my thought >train, and certainly miss the time to implement all of this. Yet my gut >feeling says this is the way to proceed as far as the architecture is >involved. If you have the energy and insight please come back to me on >this or help me convert at least a SvgBridge to make this first >increment work. Personally I will attempt to continue the work on a >ExtBridge layer and a custom Bridge for CaseTalk and see what is needed >for the communication between components to make it all work transparent= ... > >Hope you are all well and coding. ;) > >Regards, >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=3D6595&alloc_id=3D14396&op=3Dclick >_______________________________________________ >Extgraph-developer mailing list >Ext...@li... >https://lists.sourceforge.net/lists/listinfo/extgraph-developer -------------------------- Pos=EDlejte SMS p=F8es internet zdarma a bez reklamy. Pouze s TISCALI. V=EDce na http://www.tiscali.cz |
