Client code generation about loopback-getting-started-intermediate

[pulkitsinghal]

@adriatic - not sure but just checking in, are you referring to instructions around how the build process generates the angular loopback services file?

1. https://github.com/strongloop/grunt-loopback-sdk-angular
2. https://github.com/strongloop/gulp-loopback-sdk-angular

OR perhaps just everything else under the client folder?

[adriatic]

@pulkitsinghal: good observation :-) - the samples you referenced illustrate the creation of the Angular $resource file as documented here.

I am discussing creations of the extended version of the Yeoman generator which will create both server (node) and client (angular) application skeleton.

[pulkitsinghal]

@adriatic - Understood! Hope this moves forward.

You may also want to checkout https://gitter.im/loopbackers/loopbackers.github.io which is full of folks that want to create better examples that convert directly into workable projects for loopback users, perhaps striking up a conversation there may lead to more immediate results?

[crandmck]

@bajtos I'd like to bring this to your attention.

If I understand correctly, it's a reasonable suggestion, but (as the OP says) I don't think it really belongs here. If you think it makes sense, perhaps the issue should be moved to https://github.com/strongloop/generator-loopback. Then we can close this issue.

[adriatic]

I believe that the improvements could be done in stages and @pulkitsinghal's proposal to see who in https://gitter.im/loopbackers/loopbackers.github.io might be interested to help with this is a good one (for some reason I did not try that chat room yet). Here are the steps that would make the generator a lot better:

1. Add the flag "--supress-user-generation" to lb-ng tool. That way I can create the complete server-side CRUD stuff with SLC, "bring in" any Angular client code and roll my own "user/account management" (obviously I want to use Stormpath
2. Gradually augment Command-line reference (slc loopback) to include the generation of the client side (Angular initially) all CRUD code that matches the expectations by the server side and output of lb-ng. Since the slc loopback will know a lot about app (like loads your LoopBack server application, walks through all models, and generates code registering an AngularJS factory for each model) there should be a limited amount of additional data that slc would need in addition to what is already defined.

My longstanding dream to be able to use StrongLoop and Stormpath together is getting closer as a consequence of two articles I just found

• https://github.com/stormpath/passport-stormpath
• https://github.com/strongloop/loopback-example-passport

I believe that I can hack something together myself as a proof of concept, having the item 1 ("--supress-user-generation") available, which I can also do myself.

[bajtos]

Add the flag "--supress-user-generation" (...) obviously I want to use Stormpath

I am not familiar with Stormpath, does it require a loopback User model to be present on the server? If you remove the User model from the app or at least make it private (public:false in server/model-config.json), then lb-ng should skip it.

If I understand correctly, it's a reasonable suggestion, but (as the OP says) I don't think it really belongs here. If you think it makes sense, perhaps the issue should be moved to https://github.com/strongloop/generator-loopback. Then we can close this issue.

+1 for moving the issue to generator-loopback. Related: strongloop/generator-loopback#85

[adriatic]

Stormpath does not require loopback User model - it takes over the User management completely (see https://github.com/stormpath/loopback-stormpath for the definition of what the loopback-stormpath interface will be. Until that interface is not available, I would like to be able to use as much of loopback CRUD related code generation features without possible interference from the User related code. So, making User model private is a perfect solution.

[crandmck]

I don't believe that this is an issue with loopback-getting-started-intermediate per se, so I'm going to close this issue. If you still have issues that you want addressed, please open an issue in loopback, or the relevant repo.