| Age | Commit message (Collapse) | Author |
|---|
|
While making Node ID:s AttributeText:s rather than String:s is likely
the right thing to do, this approach was (expectadly) way too naive.
One needs to take proper consideration to when conversion for DOT output
is made. Possibly switching AttributeText from an enum to a struct, with
an internal representation and a preferred output format?
|
|
|
|
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.
|
|
According to the grammar of The DOT Language[1], an ID can be given in
one of four possible formats. Where the most permissive format is any
string quoted within double quotes. For generated output to be valid,
the ID strings better use that format. Since dotavious does not, and
should not, enforce that the ID only contains characters from any of the
more limited forms.
[1]: https://www.graphviz.org/doc/info/lang.html
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
rendering options I want to support so for now delete
|
|
|
|
|
|
|
|
|
|
|
|
adding basic default rust github actions workflow
|
|
|
|
|
|
|
|
use Rust's From trait
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
new trait that will provide attribute text and string
|
