@ironcode/vas-lib 0.0.18 → 0.0.20

package/lib/entity/vas-job.model.d.ts

@@ -101,53 +101,15 @@ export declare class VasJobModel extends VasRestrictedAccountObjectModel {
     /**
      * This method will hydrate the `fields` property of the model. The reason for
      * this is that we have different ways to store the field data. One way, is
-     * we store them as dynamic properties of the job e.g. job.foo.bar, the other
-     * is in an array of Field. The former is nice to work with in clients,
-     * whereas the latter more suited to relational database.
-     *
-     * A) job with dynamic properties, e.g.
-     * {
-     *   id: <guid>,
-     *   reference: "something"
-     *   <other static job properties>...
-     *   foo: {
-     *     bar: "value"
-     *   }
-     * }
-     *
-     * B) job with array of Field
-     * {
-     *   id: <guid>,
-     *   reference: "something"
-     *   <other static job properties>...
-     *   <will not have dynamic properties>...
-     *   fields: [
-     *     {
-     *       id: <guid>,
-     *       <other field properties>,
-     *       value: "value"
-     *     }
-     *   ]
-     * }
-     *
-     * What this method does is given a VasJobModel that has been populated with
-     * a VasJobDto in form B (i.e. `.fields` are populated - usually from a VASAPI
-     * response), hydrate the dynamic properties of the model. NOTE: knowledge of
-     * the Form that was used to crate the Job is required because it will contain
-     * the Groups, which names are used in the hydrating
-     *
-     * @param {VasFormModel} formModel the VasFormModel that was used to create
-     * the job
-     * @return {void}
-     */
-    hydrateDynamicProps(formModel: VasFormModel): void;
-    /**
-     * This method will hydrate the `fields` property of the model. The reason for
-     * this is that we have different ways to store the field data. One way, is
-     * we store them as dynamic properties of the job e.g. job.foo.bar, the other
-     * is in an array of Field. The former is nice to work with in clients,
-     * whereas the latter more suited to relational database.
-     *
+     * we store them as dynamic properties of the job. For example job.foo.bar,
+     * where `foo` is the name of a Group, and `bar` is the name of a control.
+     * Thus, when we create a job using a form in the client, the job object will
+     * have its static properties (id, account, reference etc), and also a number
+     * of dynamic properties determined by the Groups and Controls. This kind of
+     * object is nice to work with in certain circumstances. However, the api
+     * works differently. In the API a Job is a record, and references a number of
+     * Field records. Each Field stores the value. Comparing these two models we
+     * have:
      * A) job with dynamic properties, e.g.
      * {
      *   id: <guid>,
@@ -214,7 +176,7 @@ export declare class VasJobModel extends VasRestrictedAccountObjectModel {
      * be generated, or to reuse an existing one from the map.
      * @param {Array<string>} controlNames if a value is provided, it will be used
      * to filter the fields that are returned.
-     * @return {void}
+     * @return {Array<VasFieldDto>}
      */
     hydrateFields(formModel: VasFormModel, controlFieldIdMap?: Map<string, string>, controlNames?: Array<string>): void;
     /**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ironcode/vas-lib",
-  "version": "0.0.18",
+  "version": "0.0.20+rc1",
   "peerDependencies": {
     "angular2-uuid": "^1.1.1",
     "moment": "^2.0.0"