Presents a detailed description of how the model looks in the app.

Description

Models in ember-application class inherit from Ember Data DS.Model.

Models often have the following structure:

// The imports. 
import DS from 'ember-data';
import { Projection } from 'ember-flexberry-data';

var Model = Projection.Model.extend({
  // Own attributes, master detaily. 
  name: DS.attr('string'),
  someMaster: DS.belongsTo('new-platform-someproject-somemaster', { inverse: 'somemodel', async: false, polymorphic: true }),
  ...

  // Validation rules. 
  validations: {
    name: { presence: true }
    ...
  }
});

// Define model-ancestor (if any). 
Model.reopenClass({
  _parentModelName: '...' // Specifies the name of the model, which is inherited by this model, such as the 'new-platform-someproject-parent'. 
});

// Define views. 
Model.defineProjection(
  name: Projection.attr(''),
  someMaster: Projection.belongsTo('new-platform-someproject-somemaster', '', {
    ...
  })
  ...
});

Model.defineProjection(
 ...
});

// Export the model. 
export default Model;

Imports and exports conform to the syntax ember-cli. The model inherited from base technology class defined in the addon ember-flexberry-data. Model set view.

There are also different approaches to specify default values for the attributes of the model.

The definition of a model

The models are defined “standard” method for Ember.

Additionally, the models inherited from the base technological models are used validation model.

For attributes of any Ember models available built-in data types string (string), number (number) boolean (Boolean) and date (date). To define other data types in Ember models are used transformation.

In addition to the standard data types in the expansion ember-flexberry-data was added transformation decimal (float type), file (type “File”), flexberry-enum (type for enumerations), guid (type “GUID”, which is the default for primary keys).

For more information about using transformations for enumerations can be viewed here.

Example for a class with the master employee1 type ‘new-platform-someproject-employee’ and detaylari orders type ‘new-platform-someproject-order’.

var Model = BaseModel.extend({
  firstName: DS.attr('string'),
  lastName: DS.attr('string'),
  birthDate: DS.attr('date'),
  photo: DS.attr('file'),
  gender: DS.attr('new-platform-someproject-gender'),
  employee1: DS.belongsTo('new-platform-someproject-employee', { inverse: null, async: false }),
  orders: DS.hasMany('new-platform-someproject-order', { inverse: 'employee', async: false }),
});

The primary keys in the model

The primary keys of the object are not specified in the model explicitly. In the client code access the primary key can be done using property id.

How is the corresponding property on the server that is defined in the serializer.

The primary key type

The primary keys of the models in Ember applications are always strings, but on the server this behavior can be changed. If you change the primary key on the server, you must override a static property idType in the model class:

import { Projection } from 'ember-flexberry-data';

let Model = Projection.Model.extend({
  // ... 
});

Model.reopenClass({
  idType: '...',
});

export default Model;

Sets the property idType using static functions defineIdType in the basic technology of the model:

defineIdType: function (newIdType) {
  this.reopenClass({
    idType: newIdType,
  });
},

To call this method as follows:

Model.defineIdType('string');

Primary key is the metadata model, so the property idType defined precisely in the model and not, for example, in the adapter.

To the key type through the getMeta utilities information from the addon ember-flexberry-data.

The query language is the key type is taken into account automatically, and when building requests to the OData backendu the key values in the URL query “arabicised” only if the key type string. Currently, 3 types of keys on the client: string, guid and number. In other cases, when building requests to the OData-bakenda will throw an exception.

inverse-connection

Reference inverse-context is used, for example, when working with detaylari.

The job connection from the aggregator to detailu.

var Model = BaseModel.extend({
  ...
  orders: DS.hasMany('order', { inverse: 'employee', async: false }),
});

The job from detail to the aggregator.

var Model = BaseModel.extend({
  // ... 
  employee: DS.belongsTo('employee', { inverse: 'orders', async: false })
});