RFC: dynamic model resources in Angular [DO NOT MERGE] - #5
Conversation
Introduce a new service `LoopBack` that holds accessToken and can provide other LoopBack-related functionality in the future.
The solutions has several parts: 1. Server-side module server/lib/angular-resources.client.js server/lib/angular-resources.js This module provides a middleware (request handler) that returns Angular module defining $resource objects for all public models defined in the loopback application. It should be probably extracted to a new module, e.g. loopback-angular. 2. Server-side integration One-liner in server/app.js to install the middleware defined above. 3. Client-side changes Replace 'client/js/services.js' with the script provided by the new middleware, rename 'starter.services' to 'lbModels' in depedency configurations.
There was a problem hiding this comment.
Note: I haven't run this code to verify that the hack solves the problem as expected. When we start implementing the Angular client properly, we should add an automated test to cover this part.
There was a problem hiding this comment.
We can't depend on id being the property name that guarantees the model has been saved.
There was a problem hiding this comment.
We can't depend on
idbeing the property name that guarantees the model has been saved.
How comes that? Could you provide an example (scenario), when it does not work? Is there any other way how to detect that a model has been saved?
BTW my understanding is that LB Models are hard-coded to use id, e.g. for the purpose of REST routing - see loopback/models/model.js and loopback-datasource-juggler/lib/dao.js.
There was a problem hiding this comment.
app.model('foo', {properties: {myId: {id: true, type: 'string'}});There was a problem hiding this comment.
Thanks for the example.
Just for the record, our iOS and Android client SDKs don't support custom name of the id property either. (discussion).
There was a problem hiding this comment.
Moving the discussion about custom ids to strongloop/loopback#126.
There was a problem hiding this comment.
text/javascript is obsolete. application/javascript should be used.
There was a problem hiding this comment.
Express uses application/javascript, our template should use the same content type for the sake of consistency.
There was a problem hiding this comment.
Non-SO: http://tools.ietf.org/html/rfc4329
I stand (rather, sit) corrected!
|
I'm a little confused. I thought from our conversation today that the services.js file was 'virtual' but I see a physical file under the /client/js directory |
There was a problem hiding this comment.
this file is removed since we no longer need it
|
my 2 cents:
|
|
@seanbrookes Thank you for your comments, I'll keep them in mind.
Try this: Dealers.find(
{
'filter[where][location][near]': '-122.2577174,49.1499898',
'filter[limit]': 25
},
function() { /* success */ },
function() { /* error */ }
);It is sort of a workaround that is available out of the box. I'll look into ways how to make it easier to use - I'd like to get to something like this: Dealers.find(
{
filter: {
where: { location: { near: 'lat,lng' } },
limit: 25
}
},
// etc. |
|
Actually, the second syntax should work too (probably since loopback v1.2.0). |
|
ok thanks, I'm running 1.4 so will give it a try. |
|
Moving to a different project. |
The pull request contains a spike implementation of module that can dynamically generate Angular $resource services for all Models exposed in a LoopBack app.
The solutions has several parts:
1. Server-side module
server/lib/angular-resources.client.js
server/lib/angular-resources.js
This module provides a middleware (request handler) that returns
Angular module defining $resource objects for all public models
defined in the loopback application.
It should be probably extracted to a new module, e.g. loopback-angular.
2. Server-side integration
One-liner in server/app.js to install the middleware defined above.
3. Client-side changes
Replace 'client/js/services.js' with the script provided by the new
middleware, rename 'starter.services' to 'lbModels' in depedency
configurations.
/to: @ritch @Schoonology @seanbrookes
/cc: @raymondfeng @altsang