RC.3.2 still does not resolve missing models and model name Casing issue about loopback-sdk-builder HOT 8 CLOSED

Ok.

After deeply analyzing the situation I verified that the original approach from the StrongLoop team is to disable everything from generated client sdks, even the scope methods, so.. I will take the following approach -which I consider the best for now-:

1.- I will change the type for the private models properties to 'any'.
2.- I will remove from the scope the related methods from private models as originally implemented by the strongloop team.

At the end the generated sdk will almost unknown anything related with private models, except for the properties that will remain as any.

I'm still not sure of what will going to happen with lowercased models, again not sure if will be supported.

Cheers!
Jon

from loopback-sdk-builder.

1. You are right, I did not follow the CamelCase, loopback anyway exported in Title case. Since swagger generator also generates model names in Title case, I believe lower casing model names is okay.
2. With typing the relations and properties as "any" we should be able to bypass the problem, With "any" beta releases never caused any problems :-) it also solves any unintentional security (exposure). But that conflicts with typing it adequately. parts of related models would be required in client. (swagger generator provides all models, but only public services.)
3. The problem related to lower-casing isn't appearing for models but only relations (scopes) and properties.
4. For cases with a property object being of type "Model1", we can still run in problems where the model may or may not be exposed by remoting, resulting in another type-unvailable error. So they may also require to be typed "any". But how does swagger know of such models, probably loopback exposes one set with remoting but another with swagger.

So the immediate fixinng would be to provide "any' for scopes and properties would hidden model type. that would lead to no errors for everyone (including people like me with wrongly cased model names).

I have to commend your approach to try and providing complete typing, but that doesnt seems to be supported by available tools consistently (if swagger gets to generate all models and selected services, perhaps we're missing something)

from loopback-sdk-builder.

Following two changes correct the Title casing for properties and models: (utils.js)

    var name = c.name;
    var name = c.name[0].toUpperCase() + c.name.slice(1);

 targetClass = targetClass[0].toUpperCase() + targetClass.slice(1);
  modelClass.sharedClass.ctor.relations[scopeName].targetClass = targetClass;

After this we just need to decouple the model and service generation sources, services can be looped from the rest adapter classes, but for models we need to do something like swagger spec generator

https://github.com/strongloop/loopback-swagger/blob/master/lib/specgen/swagger-spec-generator.js#L55-L61

from loopback-sdk-builder.

This is good, let me play with it and try to come with the complete solution, hidden services but exposed models.

Still I can think, won't that be a security concern? we would expose data models that some devs may want to fully keep it within the backend, we would be generating and exposing models and properties that may be critical to a system security.

So, on RC4 I will publish the "any" workaround, but we need to think deeper if we actually want to expose models.

Cheers
Jon

from loopback-sdk-builder.

The point can be contested, but if we assume enough brainstorming was done to get the swagger specs out from loopback, we can skip that discussion until swagger.json also hides models like that. Maybe we can provide a separate flag under sdk settings for model, if that model needs to be hidden. (but then we'd require to keep the typing to "any" for all such models, which may be an overkill).

Probably we can leave that customisation to the developers rather than keeping in the tool. and OOTB generation can just generate all models and exposed APIs.

from loopback-sdk-builder.

I also had to remove following from the model.ejs to not include model.relations as properties, because it had conflict in User.credentials in case passport is used (which includes another UserCredential model as relation. Also if we're not exporting the relation model interfaces, we can skip including them in models:

now model.ejs for angular2 looks like

/* tslint:disable */

export interface <%- modelName %>Interface {
<% for (var property in model.properties) { var meta = model.properties[property]; -%>
  <% if (meta.description) { %>
  /**
   * <%- meta.description %>
   */<% } %>
  <%- property %><%= meta.required ? '' : '?' -%>: <%- getModelType(meta.type) %>;
  <%
  } // for property in model.properties -%>

}

export class <%- modelName %> implements <%- modelName %>Interface {
  <% for (var property in model.properties) { var meta = model.properties[property]; -%>
  <% if (meta.description) { %>
  /**
   * <%- meta.description %>
   */<% } %>
  <%- property %>: <%- getModelType(meta.type) %>;<%
  } // for property in model.properties -%>

  constructor(instance?: <%- modelName %>) {
    Object.assign(this, instance);
  }
}

from loopback-sdk-builder.

@sprypradeep Thanks for reporting all of these issues, In order to have a better issue organization could you please create a new issue for the different issues you may have?

I will consider this issue just for the Private Models issues, and is going to be fixed in RC4 which Im about to publish, I need the other issues to have its own number id.

Thanks!!
Jon

from loopback-sdk-builder.

Types for Private Models - Fixed in RC4

from loopback-sdk-builder.