Most applications report the URL when started (at least the apps we
are scaffolding using loopback-workspace). Constructing the URL in the
loopback core allows us to simplify the templates and reduce the amount
of repeated code.
- Move configuration of Karma unit-tests from `Gruntfile.js` to a
standalone file (`test/karma.conf.js`).
- Add a new Grunt task `karma:unit-ci` to run Karma unit-tests in
PhantomJS and produce karma-xunit.xml file that can be consumed
by the CI server.
- Add grunt-mocha-test, configure it to run unit-tests.
- Add `grunt test` task that runs both karma and mocha tests,
detects Jenkins to produce XML output on CI server.
- Modify the `test` script in `package.json` to run
`grunt mocha-and-karma` (an alias for `grunt test`).
The alias is required to trick `sl-ci-run` to run `npm test`
instead of calling directly `mocha`.
- Add `es5-shim` module to karma unit-tests in order to provide
ES5-methods required by LoopBack.
- Fix `mixin(source)` in lib/loopback.js to work in PhantomJS.
`Object.getOwnPropertyDescriptor()` provided by `es5-shim` does not
work in the same way as in Node.
Rename `loopback.getModel` to `loopback.findModel`.
Implement `loopback.getModel` as a wrapper around `findModel` that
throws an error when the model as not found.
Expose the juggler's DataSource constructor as `loopback.DataSource`.
The DataSource constructor is most useful to check
for `instanceof DataSource`, but it also makes the loopback API more
consistent, since the API is already exposing all pre-built Models.
Fix the problem where `registry.defaultDataSources` has two instances:
- `require('loopback').defaultDataSources` used by
`loopback.autoAttach()`
- `require('./registry').defaultDataSources` used by
`app.dataSource`.
I am intentionally leaving out unit-tests as the whole `autoAttach`
feature is going to be deleted before 2.0 is released.
Move isBrowser and isServer from lib/loopback to a new file lib/runtime.
Move all Model and DataSource related methods like `createModel` and
`createDataSource` to lib/registry.
Remove the circular dependency between lib/application and lib/loopback,
by loading lib/registry and/or lib/runtime instead of lib/loopback
where appropriate
This commit is only moving the code around, the functionality should
not be changed at all.
Add new API allowing developers to split the model definition and
configuration into two steps:
1. Build models from JSON config, export them for re-use:
```js
var Customer = loopback.createModelFromConfig({
name: 'Customer',
base: 'User',
properties: {
address: 'string'
}
});
```
2. Attach existing models to a dataSource and a loopback app,
modify certain model aspects like relations:
```js
loopback.configureModel(Customer, {
dataSource: db,
relations: { /* ... */ }
});
```
Rework `app.model` to use `loopback.configureModel` under the hood.
Here is the new usage:
```js
var Customer = require('./models').Customer;
app.model(Customer, {
dataSource: 'db',
relations: { /* ... */ }
});
```
In order to preserve backwards compatibility,
`app.model(name, config)` calls both `createModelFromConfig`
and `configureModel`.
Expose the juggler's DataSource constructor as `loopback.DataSource`.
The DataSource constructor is most useful to check
for `instanceof DataSource`, but it also makes the loopback API more
consistent, since the API is already exposing all pre-built Models.
Fix the problem where `registry.defaultDataSources` has two instances:
- `require('loopback').defaultDataSources` used by
`loopback.autoAttach()`
- `require('./registry').defaultDataSources` used by
`app.dataSource`.
I am intentionally leaving out unit-tests as the whole `autoAttach`
feature is going to be deleted before 2.0 is released.
Move isBrowser and isServer from lib/loopback to a new file lib/runtime.
Move all Model and DataSource related methods like `createModel` and
`createDataSource` to lib/registry.
Remove the circular dependency between lib/application and lib/loopback,
by loading lib/registry and/or lib/runtime instead of lib/loopback
where appropriate
This commit is only moving the code around, the functionality should
not be changed at all.
Use
@property {Object} [properties]
instead of
@property {Object=} properties
for optional properties.
Use `**example**` instead of `@example`, since strong-docs don't support
the latter.
Add new API allowing developers to split the model definition and
configuration into two steps:
1. Build models from JSON config, export them for re-use:
```js
var Customer = loopback.createModelFromConfig({
name: 'Customer',
base: 'User',
properties: {
address: 'string'
}
});
```
2. Attach existing models to a dataSource and a loopback app,
modify certain model aspects like relations:
```js
loopback.configureModel(Customer, {
dataSource: db,
relations: { /* ... */ }
});
```
Rework `app.model` to use `loopback.configureModel` under the hood.
Here is the new usage:
```js
var Customer = require('./models').Customer;
app.model(Customer, {
dataSource: 'db',
relations: { /* ... */ }
});
```
In order to preserve backwards compatibility with loopback 1.x,
`app.model(name, config)` calls both `createModelFromConfig`
and `configureModel`.
Allow browserified applications to explicitly register connectors
to use in data-sources via `app.connector(name, exportsFromRequire)`.
Include built-in connectors like `Memory` and `Remote` in the registry.
Modify `dataSourcesFromConfig()` to resolve the connector via
`app.connectors` first and only then fall back to auto-require
the connector module.
Support flat structure of model config objects, where model options
are set as top-level properties.
Before:
Customer: {
dataSource: 'db',
options: {
base: 'User'
}
}
Now:
Customer: {
dataSource: 'db',
base: 'User'
}
Make `loopback.rest` self-contained, so that authentication works
out of the box.
var app = loopback();
app.enableAuth();
app.use(loopback.rest());
Note that cookie parsing middleware is not added, users have to
explicitly configure that if they want to store access tokens
in cookies.
Modify `loopback.token` to skip token lookup when the request already
contains `accessToken` property. This is in line with other
connect-based middleware like `cookieParser` or `json`.
creating a cache
- Use the SharedClass class to build the remote connector
- Change default base model from Model to DataModel
- Fix DataModel errors not logging correct method names
- Use the strong-remoting 1.4 resolver API to resolve dynamic remote
methods (relation api)
- Remove use of fn object for storing remoting meta data
- Move DataModel remoting setup into setup phase
- Add a remoting type converter for DataModels
- Move model tests into re-usable test utilities
- Move other test utilities into new test utilities folder
Miroslav Bajtoš
Miroslav Bajtoš
Guilherme Cirne
Karl Mikkelsen
Raymond Feng
Samuel Reed
Raymond Feng
crandmck
Ritchie Martori
Adam Schwartz
haio
Ritchie Martori
Alex Pica
Doug Toppin
Doug Toppin
Ryan Graham
Aurelien Chivot