Added optional configs for settings

[joshkehn]

This allows the following settings variables to be set:

• TASTYPIE_SWAGGER_APP_NAME configures the display name on the documentation page. Defaults to swagger.
• TASTYPIE_SWAGGER_APP_LINK configures the app link on the documentation page. Defaults to /.
• TASTYPIE_SWAGGER_SHOW_DEV allows showing or hiding the development links. Defaults to False.
• TASTYPIE_SWAGGER_KEY_NAME allows configuring the api key name. Defaults to apiKey.
• TASTYPIE_SWAGGER_API_KEY allows configuring a prefilled api key. Defaults to an empty string.

The README file has been updated with explanations of these as well.

[rmutter]

Looks like there's one typo in the documentation and pull request description. The second TASTYPIE_SWAGGER_APP_NAME needs to be renamed to TASTYPIE_SWAGGER_APP_LINK.

[joshkehn]

Updated, thanks @rmutter for the catch.

[Seraf]

Great PR ! Should be great to have an input box on the web part for the API Key to be more dynamic and filling it by reading a default cookie like tastypie_credentials.
As docs can be embedded in a webapp that plays with the tastypie apikey, swagger ui will be able to directly use the credentials of the authenticated user.
I don't know if it's understandable, but it should be a very nice integration :)

[fehguy]

You might look at the swagger 1.2 spec, which lets the name of api keys be set in the swagger json. The UI could easily read this and populate the key name.

The authorizations info:
https://github.com/wordnik/swagger-core/wiki/authorizations

An example of such:
http://petstore.swagger.wordnik.com/api/api-docs

And an alternate UI that has the api key name driven off the spec:
https://github.com/wordnik/swagger-ui/tree/authorization

[joshkehn]

@fehguy Nice, I'll have to check that out. Currently I'm making modifications as I use it, but I'll definitely be looking forwards to making this play nice with upgraded versions of swagger.

[johnraz]

I love the idea but I would rather implement this as a dictionary ;-)

[joshkehn]

@johnraz Agreed 100%. I'm going to restructure this.

[johnraz]

@joshkehn : also make sure to make it "multi-api" ready. I guess using the app_name has the first main dictionary key should be ok ;-)

[johnraz]

@joshkehn : any chance you'd get some time soon (in the coming days) to get this done ? otherwise I think I'll do it (need it for a paid project of mine).
Thanks !

[joshkehn]

@johnraz I'll see what I can get done this weekend!

[johnraz]

Super awesome thanks :)

[johnraz]

@joshkehn : I know it's wrong but yet I friendly bump ;)

[joshkehn]

I'll work on this today, sorry life got in the way 🍧

[johnraz]

Splendid!

[joshkehn]

@johnraz I updated it to be a dictionary and updated the documentation to match. The current app I have using this I can't drop-in this branch to replace because there are some errors in mapping.py.

Let me know how this update looks and I'll pull this together into a separate branch from master and work out any kinks.

[johnraz]

I will try to give it a look tomorrow. Thanks !

[johnraz]

Ok I finally had some time to look at it.
The API_MODULE settings is deprecated and shouldn't be defined anymore.
We are now using the doc directory for read the docs, so please move the documentation there.
I suggest you rebase current master on your branch.
Other than that, LGTM.