Is there a way to specify a custom ISwaggerGenerator or invoke some method or program to produce the output swagger spec in the swaggerGenerator section of nswag.json?
The standard fromSwagger generator seems to work with only an output path, so as a last resort, I may use an exec task to create the file named there. But it would seem less hacky to specify my generator directly in nswag.json.
"swaggerGenerator": {
"fromSwagger": {
"output": "swagger.json"
}
}
At the moment, the input can be a file/url or one of NSwag’s Swagger generators (use NSwagStudio to see the available inputs).
Related
In short: I have a method name provided via a JSON configuration file. I'd like to call a method using this provided name. The method (with a matching name) will exist in the backend. What's the best way of going about this?
I am not quite sure what I should be searching for as an example.
To detail: I am working with a legacy application, hence the VB.NET. I am building a single PDF file from multiple PDF sources. Most of these are as is, I simply read the configuration and grab the relevant files and the job is done. However some require processing, I'd like the configuration file to pass in a method name to be called that will perform extra processing on the PDF, whatever that may be.
As there can be a lot of PDF files that can vary, I cannot simply use a property such as "PostProcessing: true".
Any ideas?
You could use reflection to reflect method names back and check them against the name passed from the property in the config file.
Like so
Type magicType = Type.GetType("MagicClass");
MethodInfo magicMethod = magicType.GetMethod("ItsMagic");
object magicValue = magicMethod.Invoke(magicClassObject, new object[]{100});
That would work.. but to be honest, I'd go with a case statement as you'll be hardcoding the method names anyway (because they are code), and it'll be strongly typed (less chance of typos and errors).
There are 2 styles of writing contracts used in our project.
First is to save both request and response as json files and use them to define a contract:
request {
body(file("request.json"))
}
response {
body(file("response.json"))
}
It creates stubs, that don't work unless your request is filled exactly like request.json, which makes it difficult to write unit tests with stubs for the consumer. However, using concrete values might be better for testing integration.
The second approach is to use regular expressions as much as possible:
request {
body([
clientName: $(anyNonBlankString()),
accountNumber: $(consumer(regex("[0-9]{20}")), producer("12345678901234567890")),
amount: $(anyNumber())
])
}
Stubs defined this way will be flexible, but we end up testing only presence of fields in the request and their format.
Which is the right way to write a contract?
It depends only on what you prefer. If you use the first option you can still use the bodyMatchers section where you can, using xpath or jspath, to define which parts of the body should be dynamic. It's all matter of preference.
Can you set Swashbuckle documentation for an Operation at runtime?
Example: document list of values that are allowed, which is based on an internal dictionary but could also be based on configuration.
What does not solve the problem:
Use XML documentation: sets documentation from the XML comments in code. This is static instead of dynamic.
Set global description using the AddSwaggerGen method. This is dynamic, but at the wrong level.
Using an ISchemaFilter you can do some crazy documentation.
Here is an example:
https://github.com/heldersepu/csharp-proj/blob/master/WebApi_MyGet/WebApi_MyGet/App_Start/SwaggerConfig.cs#L277
Flash builder lets me insert metadata for events fired by a class, example:
[Event("myEvent", "flash.events.Event")]
public class MyClass() {
}
Is there any way to do the same for Exceptions?
Currently I have checked here, and can't see it documented. Perhaps it's not even worthwhile, what are your thoughts.
There are ways to create your own metadata; and add that into your app at compile time. Use the keep-as3-metadata compiler argument.
It will be up to you to write code to do something with it at runtime; or to build IDE extensions to make use of the code while writing the code.
To access such metadata at runtime, you'll need to perform some type of introspection. Here are some docs and another StackOverflow Question about this.
Many Flex Frameworks make use of custom metadata.
Tridion's user interface allows you to extend specific commands, which is a great way to modify the behavior of certain existing commands. In the configuration file of the editor this is done with a section like this:
<ext:commands>
<ext:command name="TextUnderline" extendingcommand="MyTextUnderline"/>
<ext:command name="TextStrikethrough" extendingcommand="MyTextStrikethrough"/>
I am working on a generic command extension class that can be used to modify the behavior of a number of commands:
<ext:commands>
<ext:command name="TextUnderline" extendingcommand="MyCommandExtension"/>
<ext:command name="TextStrikethrough" extendingcommand="MyCommandExtension"/>
So in this second configuration fragment, we have the same MyCommandExtension extending both TextUnderline and TextStrikethrough.
But now in the JavaScript for my MyCommandExtension, how can I determine which command was originally fired?
MyCommandExtension.prototype.isAvailable = function (selection, pipeline) {
...
console.log(this.properties.name);
...
};
In this scenario the this.properties.name will be logged as a less-than-useful-but-completely-correct:
"DisabledCommand"
I suspect that the information is available somewhere in the pipeline parameter, but haven't found it yet.
How can I find out the original command from MyCommandExtension?
Short answer: I couldn't.
I had to do something similar, and ended up having to extend various commands and set the "current" command as part of my "_execute" call (so I would now call _execute(selection, pipeline, originalCommand) for my command.
N
You cannot find out what the original command is. The assumption is that an extending command is specific to the command it extends and so would know which one it is extending. When creating generic extensions that work on different commands, I can see how it might be useful to know what the configuration would be.
Maybe you could add this as an Enhancement Request?
To work around it for now, you could create a base command with your logic - which takes the name of the command that it extends as a parameter. And then create specific classes for each command you which to extend, which just call the base command and pass in the name.
To put it differently, create a BaseExtendingCommand with all of the required methods - and then both a TextUnderlineExtendingCommand and TextStrikethroughExtendingCommand which call the methods on BaseExtendingCommand (and pass in "TextUnderline" and "TextStrikethrough", respectively, as arguments)