rr
rr copied to clipboard
Extract railroad generator to reusable class
Here's my proposal for a Java API for railroad diagram generation. So why should RR have one? Personally, I plan to use it to create a Maven plugin for RR, but I imagine that having a Java API could make RR useful for a wide variety of other applications.
Notes
- The original generation code and logic is unchanged, only moved around and split. I verified that the output files for all three modes (regular, png, md) stay identical to
master
. - The new
RailroadGenerator
class uses the same default settings as the CLI. - The CLI's boolean options for choosing the output type are mapped to a single enum.
- Some setter names deviate from the previous variables in the hope of making their meaning more obvious:
- color ➞ setBaseColor()
- spread ➞ setColorOffset()
- inline ➞ setInlineLiterals()
- keep ➞ setKeepEpsilon()
- The new
RailroadGenerator
class is free of CLI-specific assumptions and defaults:- Colors are passed as
java.awt.Color
values instead of a hex strings. - The grammar is passed as a string which allows e.g. reading it directly from a UI component; existing decoding logic is kept in
Railroad
. - Exception: output still defaults to
System.out
even inRailroadGenerator
, not only set by the CLI. The reason is that I'm not yet sure how the API for specifying outputs should look like.- Background: I'm toying with the idea of a working on a PR that introduces an XHTML & PNG mode which writes individual files instead of one zip. This would not involve one specific output stream, but more likely some form of "output strategy".
- Colors are passed as
Caveats
- Some of the default settings documented in the new
RailroadGenerator
class are not implemented in that class, but in the XQuery files. This leads to some ambiguities regardingnull
. However, I think those are not really relevant. - I noticed that
usage()
does not list thepadding
andstrokewidth
CLI options. I didn't change that as doing so is arguably not within the scope of this PR. Also, the omission may have been intentional.
Looking forward to reading your opinion on this! I hope you find this work acceptable - if not, please just tell me what to change.
Here's my proposal for a Java API for railroad diagram generation. So why should RR have one? Personally, I plan to use it to create a Maven plugin for RR, but I imagine that having a Java API could make RR useful for a wide variety of other applications
I'm also interested to integrate this library in https://kroki.io/ @GuntherRademacher I would suggest to add additional maintainers to help you move this project forward. Maybe @bannmann would be interested? What do you think?
Thanks for sending this PR. I have no objections. Sorry for the delay.