Move common functionality to new model base class

[delenius]

Fixes "additional comment (2)" in #2044.

The toJson method that currently exists (identically) in every model class is moved to a common base class, ApiModel, that is extended by all model classes (using prototype inheritance).

The new ApiModel base class may also be useful for other purposes (i.e. other common functionality among the model classes) in the future.

Note: This also includes the changes to the Petstore example files from #2071 because it would be impossible not to (since I had to regenerate the example files using the latest code).

A couple of debatable points:

• The name of the common base model class could be changed. It is currently ApiModel. Perhaps you prefer BaseModel, ModelBase, or just Model?
• The base model class could be put in the model dir. Currently it goes where ApiClient.js goes.

[wing328]

We've similar model implementation (refactor model functions into a base class) for Ruby but we later remove that.

The reason is that we want to avoid extra dependency on the model as there are use cases just use the models (not API class) only.

[delenius]

I don't understand. This does not depend on an "API class" (though I called the base class, perhaps poorly, ApiModel). I put the base class in its own file. And it can even be moved into the models dir. It is a pure "model" file, and you could still use the other model classes without using the API.

[wing328]

Can the model class be used without ApiModel? (the fact that I mentioned about API class might have confused you)

In other words, we want to make the model class "self-contained" without dependency on another base class.

[delenius]

No, the model classes are not self-contained in that sense.

However, the model classes can already depend on other model classes when you have fields of some user-defined type.

Another potential need for inheritance in the model classes is to support polymorphism properly (see #2041).

In short, there is nothing wrong with having model classes depend on other model classes, and in fact you already do this.

[wing328]

There's definitely nothing wrong and as I said we did it before (with the exact reason you mentioned in this PR). I just wanted to share the reason with you why we rolled back to the original approach.

[delenius]

@wing328 since you don't want to do the refactoring above, how do you feel about simply removing the toJson method? It is not used anywhere, and it is pretty pointless, since it is always the same one-liner,

  {{classname}}.prototype.toJson = function() {
    return JSON.stringify(this);
  }

It seems more straightforward to just using JSON.stringify directly.

[wing328]

@delenius once again thanks for this PR. I was really happy when I saw it as you took a huge step further to bring the JS API client to the next level.

I agree that the one-liner (using JSON.stringify) should be pretty straightforward to most JS developers and one should also easily find the solution by doing a google search (example).

One question I always consider is can a 10-year-old who just learns JS programming for 3 months use the JS API client generated by swagger-codegen? would the toJson make his/her life easier in converting the JS models to JSON string? My view is to keep it to make a developer's life easier (which should be the primary goal is an SDK/library).

Of course, another view we also need to consider is whether the toJson function would make the JS API client looks less professional.

I've shared my view and if you want to remove toJson, please go ahead to file a PR and I'll merge.

[delenius]

I'll hold off for a little while to see if we get any tie-breaker opinion on this :)

[demonfiddler]

I'm at a loss to understand what the toJson() method is intended to accomplish. The ECMA 5.1 / JavaScript specifications define a toJSON() method that, if present, is called by JSON.stringify(object). It strikes me that adding another method with different capitalisation will lead to confusion.

Surely standard serialisation via JSON.stringify(model) is perfectly adequate? My vote is to remove the toJson() method from the template and in fact my changes for #2258 will do exactly that (I omitted to write that aspect up).

Regarding a generic base class for all models, this would be useful if and only if we had something useful to put in it. On a previous EMF-to-JavaScript project I did use a generic base class to implement the 'pure modelling' semantics of containment, bidirectional associations, runtime type safety, etc. and I suppose that at some future point we might entertain such capabilities.

Apart from that, it's possible that an abstract base model class might be useful to support polymorphism - see #2041. The generated X.constructFromObject() method would need to inspect the discriminator field to determine which sub-class to instantiate - such logic could be placed in the base model class to avoid replicating it in every (extended?) class.