I am trying to generate a python SDK for the following API definition:
https://api.youneedabudget.com/papi/spec-v1-swagger.json
When I load the json on swaggerhub everything seems fine, but the generated python code is missing some fields in the models.
As an example, consider the transactionDetail model; it should contain all the fields of TransactionSummary. In the swaggerhub interface, the model shows up correctly:
But in the generated python, the swagger_types are as follows:
swagger_types = {
'account_name': 'str',
'payee_name': 'str',
'category_name': 'str',
'subtransactions': 'list[SubTransaction]'
}
Basically missing everything from TransactionSummary.
I feel I am missing a tiny simple detail, but I am no expert in this field and was unable to solve the issue.
Related
I am in the unfortunate situation where the names of a number of the classes in my project conflict with the classes that are imported from a framework. In general, I want to use the class from the framework in almost all cases. I know that I can specify which class to use by using Framework.ClassName or Module.ClassName. However, this would require adding Framework. to a large number of types.
Is there a mechanism to default to using the framework over the current module class. I.e. in the following example can I make sure that ambiguousInstance is of type MyFramework.ClassName by default?
import MyFramework
struct MyStruct {
var frameworkInstance: MyFramework.ClassName
var moduleInstance: MyModule.ClassName
var ambiguousInstance: ClassName
}
Or, failing that, can someone explain to me the logic behind which class is used when the framework or module is not specified. I.e. in the above case, I have seen the compiler infer that ambiguousInstance is MyFramework.ClassName in some instances and MyModule.ClassName in other instances, and cannot figure out why.
Note: I know having names which can conflict with a framework is not good design, the reason I do now is that I am moving a lot of my code from iOS native to Kotlin multiplatform, and so for the migration, I temporarily have two versions of essentially the same model
I am looking to reuase some (iOS) client side code into a sample Vapor serverside project.
The code in question relies on SwiftyJSON functionality, defined as a struct JSON; now this name slot is not 'free', but already used inside a package that Vapor relies upon (the package name is JSON, as well).
While I can point to the JSON thing I want in my former client side code (as App.JSON), the controller that is boilerplated into the code also uses JSON. And apparently putting as I did the SwiftyJSON library files into the App namespace actually overrides the moduleless references to Vapor's JSON.
I tried to refer then to JSON.JSON, but it does not get recognized. JSON is a defined and compiled framework in the project. Should it not define implicitely a module name, as well?
How can I reach Vapor's JSON, then?
Thanks..
As a matter of fact, the Vapor module also exports JSON. So, the following works:
import Vapor
// Introduce a symbol collision
struct JSON {}
// Import from the Vapor module
print(try Vapor.JSON(node: "test"))
I want to write a code generator that generates a class based on the meta model of another ceylon class. I want the code generator to run at compile time. What is the best way for me to do this. I could probably accomplish this by writing a plugin for gradle or the ceylon build system but I'm hoping for a simpler solution. Unfortunately, I don't see any support for code generators in ceylon. Also, are there any plans for code generators in ceylon?
I want to write this code generator because I'm thinking about writing a simple web framework for ceylon that look at a class like the following using the meta-model:
controller
shared class Controller() {
shared void doSomething() => print("did it!");
}
I plan for it to be like Spring MVC. This framework would make a restful API from the Controller class that allows someone to write an AJAX call like this:
$http.get("/Controller/doSomething");
I want to make things more convenient, high level, and simple by doing something like GWT. I want to create a code generator that automatically generates a class like this:
shared class RemoteController() {
shared void doSomething() {
$http.get("/Controller/doSomething");
}
}
The RemoteController would be run in a user's browser as javaScript and allow client side ceylon code to do an Ajax call like this:
RemoteController().doSomething();
That would end up calling the Controller().doSomething() on the server so "did it!" would be printed.
AST Transformers have been proposed, but are still in the early design phase. For now, to do compile-time code generation, you’ll have to rig up something of your own.
To actually generate the code, I would recommend use of ceylon.ast and ceylon.formatter. The workflow would roughly be:
analyze source code –
either parse it with ceylon.ast (ceylon.ast.redhat::compileAnyCompilationUnit) and analyze it without typechecking,
or parse it using the compiler, run the typechecker, then convert it to ceylon.ast (ceylon.ast.redhat::anyCompilationUnitToCeylon), keeping the typechecker information using the new update hooks in the very soon upcoming 1.2.0 release
edit the source code AST to add your new code (using a custom ceylon.ast.core::Editor that injects new class definitions into the CompilationUnits), or perhaps create entirely new compilation units if the RemoteController lives in a different module
convert the ceylon.ast AST to a compiler AST and feed it into ceylon.formatter to turn the AST into code again (see here for an example of that)
Alternatively, if you integrate this into your build step, you could skip the ceylon.formatter part of step 3 and instead feed the converted compiler AST into the typechecker and rest of the compiler directly.
Correct me if I am wrong, but it appears that CoffeeScript does not compile/join code (each class has its own file) in the correct order.
If I have these classes in the following files:
Button.coffee
class Button extends UIComponent
UIComponent.coffee
class UIComponpent
When I compile these classes (using the --join flag), it outputs the classes in the incorrect order (i.e. putting Button ahead of UIComponent). So when the referenced .js file is used on a web page, it throws the "Cannot read property 'prototype' of undefined" error
Is this an issue that anyone else experiences? If so, is the standard use of CoffeeScript to not use classes? I'm just confused on why this doesn't appear to be a standard implementation? Perhaps I am using CoffeeScript incorrectly.
CoffeeScript isn't responsible for your dependency management.
You could use something like require.js to define your dependencies, then use CoffeeScript to compile your JavaScript files separately, and then use the r.js optimiser to minify and concatenate your compiled JS.
Not sure if i'm using the right vocabulary. In the browsable api that comes for free with django-rest-framework, I was wondering if there was a way to autogenerate a form similar to how we define ModelForms. This would allow us to more easily test input to the API in some cases.
I'm currently using ModelSerializers and the generic view APIView in case that makes a difference.
I have read the documentation (several times at this point) but didn't see it mentioned anywhere.
If you're using the generic class-based-views you'll get that for free. Try the live tutorial at http://restframework.herokuapp.com logging in as one of the users, so that you can create some snippets. eg user: 'max', password: 'max'.
Any views subclassing GenericAPIView and setting a serializer_class will get that behavior, as REST framework can determine what the form should look like.
For example:
(Note the form input at the bottom of the screen shot)
If you're just working from APIView you'll get the generic content input (such as json), like the once you've included a screenshot of, which is also useful, but not quite as convenient as the forms.
Create a serialiser class that fits the form input fields you want and set it on your APIView like so;
class MyView(APIView):
serializer_class = MySerializer # Used for the form in the browsable api
That works just perfectly.
Example of a serializer class based on a model:
from rest_framework import serializers
class MySerializer(serializers.ModelSerializer):
class Meta:
model = MyModel
class MyApiView(APIView):
"""My Demo API View"""
serializer_class = serializers.MySerializers
Make sure you're using the name "serializer_class" and not any other name like serializers_class.
using the exact "serializer_class" will autogenerate form in the browseable API