Initial version #1
Conversation
| * Documentation & Downloads: [Documentation & Download](https://extensions.xwiki.org/xwiki/bin/view/Extension/(extension name))) | ||
| * [Issue Tracker](https://jira.xwiki.org/browse/(jira id) | ||
| * Project Lead: [Farcasi Alexandru](https://www.xwiki.org/xwiki/bin/view/XWiki/Farcasut) | ||
| * Documentation & Downloads: [Documentation & Download](https://extensions.xwiki.org/xwiki/bin/view/Extension/(extension name)) |
There was a problem hiding this comment.
I will add the right link after the first release
swagger-api/src/main/java/org/xwiki/contrib/swagger/script/SwaggerScriptService.java
Outdated
Show resolved
Hide resolved
| import javax.inject.Singleton; | ||
|
|
||
| import org.xwiki.component.annotation.Component; | ||
| import org.xwiki.contrib.swagger.internal.Proxy; |
There was a problem hiding this comment.
You shouldn't import internal components in public ones.
There was a problem hiding this comment.
import internal components in public ones
That's not a problem. What is a problem is exposing internal classes in public APIs.
| * @throws IOException | ||
| * @throws URISyntaxException | ||
| */ | ||
| public String executeProxy(String url, String accessToken, String password, String username) |
There was a problem hiding this comment.
You have a method that can call sent requests to different domains and each domain needs different params. I think it would have been better to accept a map parameter rather than have a bunch of nullable parameters.
| rendering.macro.swagger.parameter.supportedSubmitMethods.description=List the operations allowed in 'Try it out', separated by commas: get, post, put, delete, head, options, patch, trace. To disable 'Try it out' completely, enter none | ||
| rendering.macro.swagger.parameter.supportedSubmitMethods.name=Supported submit methods | ||
| rendering.macro.swagger.parameter.tagsSorter.description=Definition order (default), name (alpha) | ||
| rendering.macro.swagger.parameter.tagsSorter.name=Tags Sorter |
There was a problem hiding this comment.
You also need to add some translation keys for the enumaration values. The prefix seems to be the class type: https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-web/xwiki-platform-web-templates/src/main/resources/templates/html_displayer/enum/edit.vm#L31-L32
|
|
||
| function checkIfJson(content) { | ||
| // We know that all json start with "{" so we can check if the first character is "{". | ||
| return content.charAt(0) === "{"; |
There was a problem hiding this comment.
maybe a more robust method of checking it would be to JSON.parse it
swagger-api/src/main/java/org/xwiki/contrib/swagger/internal/HttpClientBuilderFactory.java
Outdated
Show resolved
Hide resolved
swagger-api/src/main/java/org/xwiki/contrib/swagger/internal/Proxy.java
Outdated
Show resolved
Hide resolved
| import javax.inject.Singleton; | ||
| import javax.ws.rs.core.UriBuilder; | ||
|
|
||
| import org.apache.http.client.methods.CloseableHttpResponse; |
There was a problem hiding this comment.
You might want to use HTTPClient 5 instead of 4.
There was a problem hiding this comment.
Hi! @tmortagne I might be wrong, but XWiki 14.10 depends on HttpClient 4.5, and HttpClient 5 was introduced in HttpClient 5.x
There was a problem hiding this comment.
XWiki 14.10 does not embed HTTPClient 5, but it does have a dependency management for it (it's using it during the build) and more recent versions of XWiki embed it. Depending on HTTPClient 5 just means that it will be installed along with your extension (which should not be a problem) in XWiki 14.10 version until the version of XWiki which is embedding it (in which case it will just reuse whatever is already there).
It's just that if when you start doing HTTP stuff now, it's better to get the reflex to do it with the latest version of Apache HTTPClient, one less upgrade later.
| @Component | ||
| @Named("swagger") | ||
| @Singleton | ||
| @Unstable |
There was a problem hiding this comment.
Honestly, unless you have in your projct a strict policy regarding unstable API and know where to remove them (like we have in XWiki Standard, but which is very rare in contrib projects), I'm not sure using the @Unstable annotation in contrib extensions makes that much sense (the problem is that there is a good chance it stays there forever).
Initial commit: