After writing a Graphviz Dot language parser and one tree walker, I made the decision to go for a hub and spoke architecture vs a chained architecture. Where the hub was a Dot file and the spokes are multiple tree walkers.
I had already parsed the Dot language to populate an internal domain object. Next I needed to render this in a Java graphing library that allowed me to specify positional information for each node (I chose the prefuse library (http://prefuse.org)). I also knew I wanted to parse everything from one dot file that looked like so:
graph g { a [x=3,y=100] b [x=4,y=150] a--b; }
I saw two basic options:
- Update my current tree walker to read node and node attribute information, update my domain model to contain that information. Then write a converter from my domain model -> the prefuse graph object.
- Write a new tree walker that knows about node and node attribute information, and directly populates a prefuse graph object.
Option #1 seemed like a chained approach where #2 was more like a hub and a spoke. Clearly context is king, but in my context, going for a hub and spoke approach really seems like the best way to go, and looked like soooooo much less work (Option #1 has like a million pieces where #2 had like 0, really which would you do?).
I implemented option #2 and after working out the fiddly bits with prefuse it only cost 2 hours to build and test.
I think that's pretty fast.
It seems that Antlr really encourages going towards a hub and spoke architecture and in this case I think that turned out to be a really good thing. Now I have two spokes... how to build more??!?!?! If two is good more must be better right?
One mistake I made, I didn't do any unit testing of the dot language parser. The tree walkers are well tested so the parser is at least tested via integration. I haven't spent enough time figuring out how to test the parser, so I guess that's the next step that should have been the first step, oh well.
No comments:
Post a Comment