Add function to recursively ascii render Tree/Node structure

[bradleybeddoes]

This would be quite useful as a cargo sub command (this is an area we should explore for Gotham more widely) to easily allow developers to digest the set of routes exposed by an application.

Something along the lines of:

/
| - a*
|   | - b
|   |   | - c*   
|   |   | - d*
|   |
|   | - e* 
|
| - f*

• denotes Node is routable.

[tforgione]

I started to make a little function to do that (you can test it on my fork). It outputs something like this on the kitchen-sink example:

  /
  | - async * 
  | - echo * 
  | - header_value * 
  | - hello
  |   | - name * 
  |   |   | - from *

For the moment, it uses the println! macro. Maybe it would be better to implement the fmt::Display trait, or to make a function that returns a String ?

Also, there are plenty of other libs around that have to print trees on the terminal, and some of them are really beautiful, for example, there is the clang AST, that outputs this:

Maybe using colors could be a good way to indicate to the developer which nodes are routable or not.

There is also the npm ls command for node projects that shows the dependency tree using some nice unicode characters:

$ npm ls
my-awesome-project@0.0.1
├── colors@0.6.0-1
├─┬ express@2.5.11
│ ├─┬ connect@1.9.2
│ │ └── formidable@1.0.11
│ ├── mime@1.2.4
│ ├── mkdirp@0.3.0
│ └── qs@0.4.2
└── uglify-js@1.2.6

[rcaught]

Might have to push those commits on your fork @tforgione!

[tforgione]

Oops, my bad, sorry for that... it's pushed !

[bradleybeddoes]

Hey there @tforgione. I wanted to make sure you knew we haven't forgotten about this and that we do appreciate the effort here. Right now @smangelsdorf and I both have a bunch of work that "pays the bills" which is keeping us pretty busy 😩 🔥.

I promise we'll circle back around to this discussion in the near future.

fwiw as a quick thought that screenshot looks really nice, I suspect colour would be a great way to help visualise the various parts of a route tree.

[tforgione]

Thanks for the message. Don't worry, I totally understand. Don't hesitate to comment back when you have more time to spend on this! 😄

[bradleybeddoes]

Noting this crate which was featured in Rust weekly that may be of use here:

https://crates.io/crates/colored

[tforgione]

Yes, colored seems to be a pretty cool crate.

I modified a little bit my code, to have something a little more beautiful. Now it looks like this (and use colored as a dependency):

I willingly duplicated parts of this tree so I could see if the branches were displayed correctly.

I used bold to represent routable nodes, because I didn't know what color to use.

What do you think of this ?

[bradleybeddoes]

Hey @tforgione that looks like it is coming along really well. How did you find working with colored?

I'll grab your fork later today and have a play.

@smangelsdorf something you might be interested in looking at too given router branch/work.

[tforgione]

Colored seems definetely good. It's really easy to use and it seems to be done the right way even though I not very advanced in rust.

The only thing is that it doesn't support windows terminals (yet). I really like to have portable code but I also know that almost all colored equivalent in other languages don't support windows terminals either so...

[bradleybeddoes]

Hey @tforgione any chance I could get you to rebase onto master so I can try this out against a decently sized gotham app I have?

[tforgione]

Ok, so I pulled your master branch on my fork's master and I merged my print-tree branch onto it. Let me know if you need anything more !

[bradleybeddoes]

Ok so I finally got a look at this, rendered out structure just fine for a compact application but it didn't seem to run on a modular app (definitions) and I know why, a modular app has multiple router instances which this code cannot yet deal with (as you'd expect for a PoC!).

I also note that my tree didn't seem to get any bold output, possibly due to my zsh config, not sure.

@smangelsdorf you might like to give this a look. I'm thinking this could be a suitable initial candidate for a gotham-cli crate that we've spoken of previously (for others this is how diesel handles command line tooling which seems like a reasonable approach to us).

Ideally the code for command line tools would live in their own modules within this crate and not touch, or minimally touch Gotham core, harder here given TreeBuilder doesn't exist once Router is finalized .

@tforgione it might be worth having a look at #70 as it may impact some of the thinking on how to best implement this.

cc @rcaught who was pondering this area at one point as well for any other thoughts/approaches.

[tforgione]

a modular app has multiple router instances which this code cannot yet deal with

I don't know much about modular apps, do you have any example on github that I could try ? I see the kitchen sink example has been updated in #70. Does this make it a modular app ?

I think the best way to do it would be to iterate over the different router instances and print the tree of each one. This should be doable without too much problem.

I also note that my tree didn't seem to get any bold output, possibly due to my zsh config, not sure.

Maybe we should test with another color to see if the problem is linked to the bold thing, or if it's a global bug.

[tforgione]

Hi,

I see there have been many changed in this project since my last comment. I've update my fork according to those changes, and I added render_ascii methods on both Tree and Router.

I also updated the some examples so it shows the tree before starting the server.

On my computer, it looks like this on the examples/routing/association example:

I still haven't seen any modular app, but I guess it wouldn't be much difficult to implement this on multiple routers.

[bradleybeddoes]

Hey there @tforgione. Firstly, I want to apologise for not having given this the attention I should have in the last few months. I'd like you to know that it is important to us and we do very much appreciate your contributions.

The only justification I can offer is that both @smangelsdorf and myself have been so slammed in getting ready for 0.2, working full time jobs and undertaking personal commitments that there just hasn't been enough hours in the day.

Now that we've shipped 0.2 I am going to take a few nights off from open source and catch up on some other activities I've been neglecting of late. I suspect @smangelsdorf will do the same 😃.

However early next week I am going to start implementing #120. Once I do that we can properly see how your code will work with multiple routers or adjust it to do so if necessary.

This may also lead to a wider discussion of the need for a gotham-cli crate.

One quick thought I did have whilst looking at your screenshot above is that detail around supported HTTP verbs is not shown, I am wondering if it somehow should be, though that may clutter the output as well, hmmmm......

[tforgione]

Firstly, I want to apologise for not having given this the attention I should have in the last few months.

Don't worry, nothing is in hurry so we're cool!

I'd like you to know that it is important to us and we do very much appreciate your contributions.

Thanks, I also hope that this could be the beginning of more contributions!

Now that we've shipped 0.2 I am going to take a few nights off from open source and catch up on some other activities I've been neglecting of late. I suspect @smangelsdorf will do the same smiley.

Enjoy! 😃

However early next week I am going to start implementing #120. Once I do that we can properly see how your code will work with multiple routers or adjust it to do so if necessary.

I didn't see that issue, I should've checked that... I'll keep that in mind and try to update accordingly!

One quick thought I did have whilst looking at your screenshot above is that detail around supported HTTP verbs is not shown, I am wondering if it somehow should be, though that may clutter the output as well, hmmmm......

Yes, I feel like that could be a good idea. I'll try something and let you know!