Support for tags

[nknapp]

bootprint-swagger does not yet group methods by their tag and display tag descritpion (like swagger-ui does). If anyone wants to implement this. I believe the following changes are needed:

• lib/preprocessor.js must be changed to group methods by tag (see the documentation for details about the preprocessor
• partials/base/body.hbs must call a new partial instead of {{> swagger/path}}

[erikvanzijst]

Whoever ends up working on this, it would also be very nice if the tags can act as interactive filters on the page, in a similar way to how swagger-editor allows narrowing down large API definitions based on tags.

[nknapp]

My plan was actually more like in the swagger-ui to group operations by their tags. I haven't planned to add interactive components yet, because I always had the use-case of "generating a PDF and printing it" in the back of my head.

But maybe you are right. Even if this is a static offline documentation that you can send by mail, filters like that would be nice. There could even be an input field that filters resources by their name...

[nknapp]

I have implemented a tag-based table-of-contents for now. I would like to collect and discuss interactive features #29 and I have added your proposal. There are currently no js-libraries like jquery included and there is currently no clean way to do so.
I already had thought about refactoring bootprint to use customize, which would allow a clean solution to integrate scripts and interactivity. This will take some time and I would put the priorities to supporting the whole Swagger-2.0 specification before adding such features.

@erikvanzijst: We will get filters some time. But for now, I would like to stick with the current implementation

[erikvanzijst]

Thanks, that was very quick! I gave 0.6.9 a go and tags are working.

I'm evaluating bootprint-swagger for potential use as Bitbucket's upcoming API documentation overhaul, so I appreciate the quick fix!

[erikvanzijst]

We will get filters some time. But for now, I would like to stick with the current implementation

Absolutely. I agree that full 2.0 support is more important. I also think the current lack of javascript is great for offline use and so interactive elements are not a requirement for me.

[nknapp]

That's great. If there are any parts of the spec, that are missing as features or issues, please let me now.