Hi Claudio, > the thing is: even if (for example) edge weights are supported in ALL the > file formats of the world (which is quite plausible), the actual attribute > will likely be called in different ways for each format: "weight", "w", > "value" or whatever. So even a unified implementation in AbstractExporter > should still rely on concrete implementations to discover the name of the > attribute (see e.g. the static fields DotExporter.WEIGHT and > DotExporter.LABEL).
OK! > But it's still fine for me to keep at least the abstract > common denominator. OK sounds a reasonable compromise! > > Another issue I'm facing: some of the output formats depend on the actual > type of the printed value. For example in the DOT format, Strings > (especially those with whitespaces) should be double-quoted while numbers > (doubles) should not, e.g.: > > * 192 [label="hello world" weight=3.4] > > So we should also seek a unified way to keep track of attribute types when > serializing them, so that each exporter can choose the appropriate output > format for each of them. I saw the > "enlistVerticesProperty"/"enlistEdgesProperty" methods in the code, are they > supposed to help on this matter? > I honestly started prototyping that method because of the need of GraphML of enlisting all properties first :S Can't you discover the propert type simply by checking the returned object class? Thanks for taking care of it! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org