Well, codegen works of the OAI / Swagger Specification, so you cannot just 
invent a new syntax.  You can, however, use extensions in the definition in the 
allowable places, which are passed on to the generator and usable in templates.

Take a look at 
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md 
<https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md> for 
details on where they are allowed, and look in the templates in here:

https://github.com/swagger-api/swagger-codegen/tree/master/modules/swagger-codegen/src/main/resources
 
<https://github.com/swagger-api/swagger-codegen/tree/master/modules/swagger-codegen/src/main/resources>

You can access extensions like this;

{{vendorExtensions.x-your-extension}}

> On Sep 27, 2016, at 12:21 AM, HIROSHI KOIDE <[email protected]> wrote:
> 
> Hi Tony,
> 
>  Thanks for your reply. I'm wondering if swagger codegen allows us to define 
> my own custom yaml definition. I tried to find it, but no clue. Do you happen 
> to know it?  
> 
> thanks 
> 
> On Monday, September 26, 2016 at 7:32:00 PM UTC-7, tony tam wrote:
> Hi, I have to say, this is pretty specific to your use case and difficult to 
> automate.  The best solution would be to create a custom template set.
> 
>> On Sep 26, 2016, at 2:23 PM, HIROSHI KOIDE <hko...@ <>gmail.com 
>> <http://gmail.com/>> wrote:
>> 
>> Hi experts,
>> 
>>   I'm using swagger to auto-generate JAX-RS server side code. It works 
>> great. Regarding to the codegen behavior, I'd like to ask you a question. 
>>   Say, I have next yaml definition (this is the example to explain my 
>> question). 
>> 
>> ---
>> swagger: '2.0'
>> info:
>>   version: 0.0.0
>>   title: Simple API
>> paths:
>>   /message:
>>     get:
>>       responses:
>>         200:
>>           description: OK
>>           schema:
>>             $ref: '#/definitions/message'
>>   /secureMessage:
>>     get:
>>       responses:
>>         200:
>>           description: OK
>>           schema:
>>             $ref: '#/definitions/secretMessage'
>> definitions:
>>   message:
>>     type: string
>>   secretMessage:
>>     type: string
>> 
>> 
>>   The generated server side java code has data model class Message.java and 
>> SecretMessage.java. Both have next toString() and toIndentString() methods 
>> by default (I'm using the default template).
>> 
>>   @Override
>>   public String toString() {
>>     StringBuilder sb = new StringBuilder();
>>     sb.append("class Message {\n");
>>     
>>     sb.append("}");
>>     return sb.toString();
>>   }
>> 
>>   /**
>>    * Convert the given object to string with each line indented by 4 spaces
>>    * (except the first line).
>>    */
>>   private String toIndentedString(java.lang.Object o) {
>>     if (o == null) {
>>       return "null";
>>     }
>>     return o.toString().replace("\n", "\n    ");
>>   }
>> 
>>   Basically, I'd like to leave these methods, but I don't want to print the 
>> value for SecretMessage.java. 
>>   How can we achieve this in generic way? 
>> 
>>   One solution is, providing a custom template and determines the definition 
>> of toString() and toIndentedString() based on the data model class name. 
>> This works fine, but we need to know the data model class names that we 
>> don't want to print the value in advance. It is not smart. 
>> 
>>   It may be a shallow brained idea, but I'm feeling that it's smart if we 
>> could direct this kind of things in yaml definition. Can we customize yaml 
>> definition for swagger? 
>> 
>> definitions:
>>   message:
>>     type: string
>>   secretMessage:
>>     type: string
>>     option: doNotPrintItsValueInLog
>> 
>> Probably, there should be smarter way. Please provide me some suggestion. 
>> 
>> thanks in advance.
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Swagger" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Swagger" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected] 
> <mailto:[email protected]>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Swagger" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to