| Age | Commit message (Collapse) | Author |
|---|
|
Ideally there should be test cases validating that strings longer than
80 characters are getting line breaks injected, but such tests would
likely fail.
|
|
A user, Martin, reached out about a bug with IDs specifically with
quoting. Dotavious initially just used the string provided by caller
however this is problematic for a few different scenarios amongst others
1. Strings with spaces
2. Double-quoted strings
3. Strings with non-alphanumerical content
Details about IDs can be found at https://graphviz.org/doc/info/lang.html
This commit conditional formats IDs based on the following
1. Wrap string in quotes if containing non alpha-numerical characters
2. Escape quotes found in string
My rationale for conditionally formatting is mostly around keeping
previous behavior intact. Quote from the link above
An ID is just a string; the lack of quote characters in the first two forms is just for simplicity.
There is no semantic difference between abc_2 and "abc_2", or between 2.34 and "2.34"
Given these IDs are semantically the same I wanted to keep the same
formatting which is unquoted.
NOTE: This does not address HTML strings as IDs which needs to be
addressed at a later date.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
