| Age | Commit message (Collapse) | Author |
|---|
|
|
|
always have to perform a .to_string
|
|
|
|
|
|
This adds some attribute constraints. We validate certain constraints
based on information from http://www.graphviz.org/doc/info/attrs.html.
Validation errors are collected as part of builders, we still add the
attribute regardless or not if it fails validation, and build methods
return ValidationResult<T> where errors is a Vec<ValidationError>. We
still add attributes even if the validation fails so that users can
ignore validation errors and build appropriate struct.
|
|
|
|
I didnt think we were getting a ton of benefit from the
AttributeStatement abstraction so I replaced it with IndexMap which
the attribute statement impl were using internally.
While the DOT language docs (https://graphviz.org/doc/info/lang.html) do
call out attr_stmt as part of the language definition the overhead of
the related traits, impl, structs, etc felt a bit heavy. In particular,
supporting the ability to create them as part of a build as well as
allowing users to add to them via other bulid fns was a bit awkward.
For now I think removing the abstraction makes sense and provides for a
simpler implementation. Can revisit this down the road if other
requirements come up that perhaps warrant the addittional code.
|
|
|
|
|
|
|
|
|
|
|
