-
Notifications
You must be signed in to change notification settings - Fork 44
Add support for external types and objc decorations #302
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
…ecorations similar to java decorations
| "type": "object", | ||
| "properties": { | ||
| "name" : { "type": "string" }, | ||
| "externalType": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
consider renaming to "myCustomClass"
| case let .object(schemaRoot): | ||
| return [schemaRoot.className(with: self.params)] | ||
| if schemaRoot.external { | ||
| return [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
add comment to indicate that we expect developer to use an import decoration
RicoYao
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good for Android changes
This PR implements ability to reference application classes from the schema.
A property of type
objectcan now reference an existing class in the codebase that will not be generated by plank but should still conform to the expected protocols.example usage:
When plank compiler finds
x-external:true, it will mark the SchemaObjectRoot as external, which will prevent it from trying to generate that model object. Anx-typenameis required, otherwise, it will fail code generation.On Java, it will just use the class as if it exists. Unless the class is not in the same package, it needs to be imported using the existing java_decorations feature.
java decorations file:
On ObjC, it will just use the class as if it exists. I've implemented ObjC decorations support, similar to Java, which allows specifying
swiftpackage imports that will be imported from the generated.mfile.objc decorations file:
This will generate:
In ObjC header, we also need to declare a forward reference for it, which is automatically added if there is a referenced external type. (each of these types are added to the
ObjCIR.Rootenumaration)Lists and Maps
I've not implemented support for external classes and list and map types. It requires a bit more logic when generating gson, hence skipped it for now. We still detect it and fail w/ an explicit error, in case someone tries to use it.
Examples Update
I've added decorated examples to demonstrate both x-external and decorations support. Added a test to the ObjC code to validate serialization-deserialization for the type with external data.
Other relevant but misc changes:
iOS External Class Requirements
External classes should implement the following protocols:
External classes should implement the following functions:
Android external class requirements
Custom android classes should register a GSON type adapter when deserializing.
They should also implement:
equals & hashcode