| 67 | | == 2.2 `svg` Class (current) == |
| 68 | | All of the design decisions for the `svg` class are motivated by the fact that the `svg` class is the parent for the `svg_plot` class. As such, I tend to treat it as a second-class citizen. My personal tendency is to make it purely a computation and drawing class, and leave all interface work to the `svg_plot` class |
| 69 | | |
| 70 | | When I designed the prototype, I made the svg class have a user interface much in the way that the `svg_plot` class does with the stream operator. However, as I look at the list of features that I'd like the user to be able to access, I will consider the ramifications of removing a user interface for the svg portion, and instead focus it on being the functional backbone of the svg_graph class. I will post to the Boost discussion board and see if people are more interested in eventually having a fully-functioning SVG suite, or more interested in having a fully-functioning graphing utility in the near future. |
| 71 | | |
| 72 | | == 2.2.1 `svg` Class (planned) == |
| 73 | | The architecture that I plan on creating in order to allow for future DOM support is as follows: all SVG data can be grouped in <g> tags, and the format allows infinite branching of <g> tags. I feel that if I make the internals of my `svg` class a tree structure of <g> nodes and their sub-elements, this will be conducive to proper DOM development |
| | 67 | == 2.2 `svg` Class (planned) == |
| | 68 | The internal architecture of this class (as far as being a data structure for storing a SVG document) is as follows: |
| | 69 | One can consider a `<g>` tag as the branch element of a document. Not currently (but soon!) the `<g>` element will store full information on the styles of all elements that are listed underneath it. Each `<g>` element has a Boost.ptr_vector of tag elements, and soon this will allow (theoretically) infinite branching of the <g> tags, much as the standard would allow. This stores the document XML tree in a literal tree data structure, which I feel makes more sense. A more specific implementation of the internals will most likely come at a date in the near future. |
