RAML to HTML documentation generator.

In raml1.0 branch, I write a JSON string in example field, but it will show [object Object].

Problem

/box:
  get:
    responses:
      200:
        body:
          application/json:
            example: |
              {}

to

I didn't like the UI/X of the modal dialog, and it disallowed the ability to look at more than one at a time. This is a possible solution; which may still need some cleanup but gets the idea across.

uriParameters did not show up in paths like this /something/{id}/something/{foo}/bar

In this case, uriParameters was completely empty. My code change allows both {id} and {foo} to show up.

However, I'm new to handlebars and couldn't figure out how to make this a conditional. i.e. now uriParameters show up whether it's populated or not.

Also, this is probably not the best way of doing this, so if you have a better idea and hadn't noticed the bug, you should probably scrap this ;)

Since 2.5.0 introduced a lot of changes and conflic resolution when merging develop back to raml1.0 was almost impossible, @kevinrenskers asked to basically create a new branch and apply all the changes. This PR does that. Several notes here:

• I had to change the ramlObj.securitySchemeWithName function back using a for instead of find since it was not working.
• There are some displaying issues (see images below)

Can everyone who participated updating the RAML 1.0 branch check this again please and give a LGTM? (cc/ @ivokh @edentsai @jerrobertson)

It was quite some work and I really hope I did not miss anything. The tests that I have run look good to me.

Displaying issues:

Here the rendering for the second property that is also a type is really strange - it should be a bullet point

Should we really display Type: if there is no type.

Hi,

I missed a possibility to link directly to opened modal. So I implemented this feature.

• link links directly to #{{../uniqueId}}_{{method}}
• jquery observes hashchange event

The examples are also regerenerated. It can be seen here as well: http://rawgit.com/zbycz/raml2html/patch-1/examples/example.html#_forecasts__geoposition__get

Thanks for merging or any comments :-)

Hey,

this PR adds support for themes to add their own assets to the output directory of the html file. The primary reason for adding this feature is that I need a theme that bundles its assets in order to provide api documentation on local networks that don’t have access to the internet.

Themes may define a copyAssets method as part of their config. If they do the function will receive the target directory of the output file as their only argument and should return a Promise to indicate completion. I thought about adding some logic to handle things like strings as arguments for the copyAssets config option, but that is likely to fall short in terms of what people might want to do with this. The theme should know best how to handle its assets.

I wasn’t quite sure where to add the documentation for this. If there is a theme guide somewhere I'll be happy to submit a pull request.

Thank you for your time and your work you put into this project!

This fixes #9. Steps taken:

1. Added function parseSource() to take a source (can be a string to be backwards compatible or an object containing either file, data or obj property). It returns the corresponding RAML object.
2. Refactored HTML generation out in its own function compileRamlObj().
3. Updated parseWithConfig() to invoke parseSource() followed by compileRamlObj() with the RAML object.
4. Updated main call to parse() to reflect that source argument now can be an object.
5. Added parseSource() to exported functions.

Improvement for ticket #377.

Adds an --audience parameter that allows passing a value to the template. This allows conditional formatting of the output.

I've created an organization on Docker Hub and pushed the first version of raml2html 3.0.0 image. If you're interested in merging it, I can transfer the ownership to you and describe how to build images when the new version is released.

If we use '//' instead of specifying a protocol, then we don't actually need to care what protocol the user's server is using.

(Sorry, I submitted the previous pull request before I'd actually read the entire README. Rebased on your develop branch and now resubmitting.)

This PR solves the problem also discussed in #50.

Pro:

• fixes neglected endpoint descriptions

Con:

• will generate an even more condensed documentation, so we're losing some usability value given with overview description being visible initially.