This is a very big refactor which will hopefully make it easier to interact with geo-svg. While implementing some new advanced features I stumbled across a hurdle again which I tripped over many times before:
The fact that the old Svg type captured some life times made it really impossible to generate a svg from some temporarily available data.
This was the case since the old approach kept all the references to the data sources as long as possible in memory to make it possible to apply the styles at the very last second. Although this approach enables you to render the same data with different styles, I would argue that this was a design mistake.
The new design stream-lines the svg generation a bit more and clearly separates defining a style for each svg part from adding the data that should be rendered for that part. This is done with the builder pattern.
First we build a style for some part of the svg
After that we add the shapes that the style should be applied to
Only then we can finish our svg document
To achieve almost-feature-pairity, there is also
a way to combine several svg documents into one
a way to apply some fall back general style to a svg document
The most notable difference is that we can't apply styles to groups of shapes. The behavior is still achievable but with another pattern:
old
let group_style = todo!("...");
let general_style = todo!("...");
let [svg1, svg2, svg3] = todo!("...");
let result = (svg1.and(svg2).with_style(group_style)).and(svg3).with_style(general_style);
new
let group_style = todo!("...");
let general_style = todo!("...");
let svg1 = SVGDocument::style_builder().use_style(group_style).finish_style(); // ...
let svg2 = SVGDocument::style_builder().use_style(group_style).finish_style(); // ...
let svg3 = todo!("...");
let result = svg1.and(svg2).and(svg3).use_style(general_style);
That means you have to specify the style for a group of svgs on each individual svg. I would argue that this isn't that much of a problem though, since you can just define a group_style as in the examples above and reuse it. There's even a way to specialize the style after setting it with use_style. Say you wanted to have the two svgs in different colors than you would just write:
let svg1 = SVGDocument::style_builder().use_style(group_style).with_fill_color(red).finish_style(); // ...
let svg2 = SVGDocument::style_builder().use_style(group_style).with_fill_color(blue).finish_style(); // ...
This is a very big refactor which will hopefully make it easier to interact with
geo-svg
. While implementing some new advanced features I stumbled across a hurdle again which I tripped over many times before:The fact that the old
Svg
type captured some life times made it really impossible to generate a svg from some temporarily available data.This was the case since the old approach kept all the references to the data sources as long as possible in memory to make it possible to apply the styles at the very last second. Although this approach enables you to render the same data with different styles, I would argue that this was a design mistake.
The new design stream-lines the svg generation a bit more and clearly separates defining a style for each svg part from adding the data that should be rendered for that part. This is done with the builder pattern.
To achieve almost-feature-pairity, there is also
The most notable difference is that we can't apply styles to groups of shapes. The behavior is still achievable but with another pattern:
old
new
That means you have to specify the style for a group of svgs on each individual svg. I would argue that this isn't that much of a problem though, since you can just define a
group_style
as in the examples above and reuse it. There's even a way to specialize the style after setting it withuse_style
. Say you wanted to have the two svgs in different colors than you would just write:TODOS