Conversation
ianpartridge
left a comment
There was a problem hiding this comment.
I'd like to split up the update to SwaggerUI and the other fixes into separate PRs.
| let indexPath = "file://" + swaggerUIInstallation + "/index.html" | ||
| if let indexLocation = URL(string: indexPath) { | ||
| do { | ||
| try rendered.write(to: indexLocation, atomically: true, encoding: .utf8) |
There was a problem hiding this comment.
I'm not sure this is a viable option - what if we are running in the cloud and can't write over the file?
| } | ||
|
|
||
| router.get(path) { | ||
| var apipath = path |
There was a problem hiding this comment.
Instead of this you can do guard var above.
| let template = "index.stencil" | ||
| let swaggerUIInstallation = sourcesDirectory + "/swaggerui" | ||
|
|
||
| let fsLoader = FileSystemLoader(paths: [Path(swaggerUIInstallation)]) |
There was a problem hiding this comment.
Instead of using PathKit, would FileManager from Foundation do? That would be preferable.
|
|
||
| if let rendered = try? environment.renderTemplate(name: template, context: context) { | ||
| router.get(uPath) { request, response, next in | ||
| response.send(String(describing: rendered)) |
There was a problem hiding this comment.
Can we use the new Codable templating we added in Kitura 2.4? https://developer.ibm.com/swift/2018/05/31/type-safe-templating/
There was a problem hiding this comment.
I had a play with this. There's a couple of problems:
- The template we are trying to serve is within the
Kitura-OpenAPIdependency, not within the user's application, so the template is not in the usual place (./Views). And we don't want to mess with the user'sRouter.viewsPathsince that would break their own templating. - By using the KituraStencil templating (where we register a template engine), we're required to register a StencilTemplateEngine with the user's Router - which could conflict with their own code.
| @@ -0,0 +1,299 @@ | |||
| /** | |||
There was a problem hiding this comment.
Ugh do we really have to copy and paste all this?
There was a problem hiding this comment.
The alternative is to make KituraTest and KituraTestBuilder part of a separate project which is imported as a test dependency.
Neil and I discussed this, but because SPM does not have 'test dependencies', it would have the side-effect of introducing a common dependency to Kitura and (potentially) many other repos that depend on Kitura. Unlike other common dependencies (eg. LoggerAPI), we'd probably find ourselves needing to change the base Kitura test classes relatively frequently - eg. to add new functionality - which I anticipate would cause headaches for keeping our packages in a resolvable state.
Include a up to date version of the swagger ui into Kitura-OpenAPI.
The swagger ui has been given a Kitura look with new colours and icons
Changes to the config to ensure that api and swaggerui locations can be altered whilst allowing the swaggerui to still find the correct api location.