TimePhasedProjectModel

The listener set for this object.

An object whose property names are the names of events to handle, or options which modifiy how the handlers are called.

See addListener for details about the options.

Listeners can be specified in target class config and they will be merged with any listeners specified in the instantiation config. Class listeners will be fired first:

class MyStore extends Store({
    static configurable = {
        listeners : {
            myCustomEvent() {
            },
            load : {
                prio : 10000,
                fn() { // this load listener handles things first }
            }
        }
    };
});

let store = new MyStore({
  listeners: {
    load: () => { // This load listener runs after the class's },
    ...
  }
});

Handlers as function name

Object event handlers may be specified as a function name. If a string is specified, it is the name of the function in the thisObj object.

If the string begins with up., this object's ownership hierarchy (if present) is scanned for an object which implements that function name:

new Popup({
    tbar : {
        items : {
            myCombo : {
                type      : 'combo',
                editable  : false,
                label     : 'Type',
                listeners : {
                    // Look in owner chain for this function name
                    change : 'up.onFilterChange'
                },
                items     : [
                    'Event',
                    'Task',
                    'Appointment'
                ]
            }
        }
    },
    items : {
        ...
    },
    onFilterChange({ value }) {
        // Handle event type selection here
    }
});

Convenience shortcut to set only the url to load from, when you do not need to supply any other config options in the load section of the transport config.

Using loadUrl:

{
    loadUrl : 'read.php
}

Equals the following transport config:

{
    transport : {
        load : {
            url : 'read.php'
        }
    }
}

When read at runtime, it will return the value from transport.load.url.

Has a corresponding runtime loadUrl property.

Convenience shortcut to set only the url to sync to, when you do not need to supply any other config options in the sync section of the transport config.

Using loadUrl:

{
    syncUrl : 'sync.php
}

Equals the following transport config:

{
    transport : {
        load : {
            url : 'sync.php'
        }
    }
}

When read at runtime, it will return the value from transport.sync.url.

Has a corresponding runtime syncUrl property.

By default, the stores of a project use the raw data objects passed to them as the data source for their records if data is loaded remotely (using an AjaxStore or a CrudManager). For data supplied inline, the data objects are instead by default cloned to avoid the original data object being modified by the store.

See useRawData for more information on the mechanics of this.

This can be explicitly controlled per store by setting the useRawData config on the store:

// Opt in for a single store
const project = new ProjectModel({
    eventStore : {
      useRawData : true
    },
    ...
});

Or you can control it for all the default stores in the project by setting this config on the project:

// Opt in for all stores in the project
const project = new ProjectModel({
   useRawData : true,
   ...
});

Enables early rendering in SchedulerPro, by postponing calculations to after the first refresh.

Requires event data loaded to be pre-normalized to function as intended, since it will be used to render before engine has normalized the data. Given un-normalized data events will snap into place when calculations are finished.

The Gantt chart will be read-only until the initial calculations are finished.

Set to true to enable calculation progress notifications. When enabled the project fires progress event.

Note: Enabling progress notifications will impact calculation performance, since it needs to pause calculations to allow redrawing the UI.

Has a corresponding runtime enableProgressNotifications property.

Maximum range the project calendars can iterate. The value is defined in milliseconds and by default equals 5 years roughly.

new SchedulerPro({
    project : {
        // adjust calendar iteration limit to 10 years roughly:
        // 10 years expressed in ms
        maxCalendarRange : 10 * 365 * 24 * 3600000,
        ...
    }
});

Setting this to true (default) vetoes silenceInitialCommit effect by preventing silent changes accepting on initial data loading if some scheduling issue gets resolved during it.

Enabling this config allows an application to persist the data in a resolved state.

Experimental hook that lets the app determine if a bound dataset needs syncing with the store or not, and if it does - which records that should be processed. Only called for stores that are configured with syncDataOnLoad: true (which is the default in the React, Angular and Vue wrappers).

The main use case for this is for frameworks that update all state on any state change (like React), to not have to reapply the full bound dataset each time (which becomes costly).

If the app has a cheap way of determining (for example using a timestamp) that the dataset has no changes, return false from this hook to prevent the store from syncing at all at that time.

shouldSyncDataOnLoad({ store, data }) {
  if (store === myEventStore && timestamp <= lastUpdateTimestamp) {
    // Prevent sync when the event store has not changed since last time
    // (pseudocode)
    return false;
  }
}

If the app knows that something has changed, return a Set with ids for the records that should be further processed by the sync logic.

shouldSyncDataOnLoad({ store, data }) {
  if (store === myEventStore && timestamp > lastUpdateTimestamp) {
    // Sync only these records (pseudocode)
    return new Set([6, 110, 586]);
  }
}

Has a corresponding runtime shouldSyncDataOnLoad property.

Silences propagations caused by the project loading.

Applying the loaded data to the project occurs in two basic stages:

1. Data gets into the engine graph which triggers changes propagation
2. The changes caused by the propagation get written to related stores

Setting this flag to true makes the component perform step 2 silently without triggering events causing reactions on those changes (like sending changes back to the server if autoSync is enabled) and keeping stores in unmodified state.

This is safe if the loaded data is consistent so propagation doesn't really do any adjustments. By default the system treats the data as consistent so this option is true.

new SchedulerPro{
    project : {
        // We want scheduling engine to recalculate the data properly
        // so then we could save it back to the server
        silenceInitialCommit : false,
        ...
    }
    ...
})

Set to a IANA time zone (i.e. Europe/Stockholm) or a UTC offset in minutes (i.e. -120). This will convert all events, tasks and time ranges to the specified time zone or offset. It will also affect the displayed timeline's headers as well at the start and end date of it.

There is currently no built-in time zone support in JavaScript which means that the converted dates technically still are in the local system time zone, but adjusted to match the configured time zone.

DST

If a IANA time zone is provided, there will be support for DST. But if local system time zone has DST that will affect the time zone conversion at the exact hour when the local system time zone switches DST on and off.

For example:

1. The local system time zone is Europe/Stockholm (which is UTC+1 or UTC+2 when DST).
2. The date 2022-03-27T07:00:00Z (which is UTC) is converted to America/Chicago (which is UTC-6 or UTC-5 when DST).
3. The converted JS date will be created from 2022-03-27T02:00:00 which is exactly the hour when Europe/Stockholm adds an DST hour. This has the effect that the converted date shows up incorrectly as 2022-03-27T03:00 instead.

If a UTC offset is provided, there is no DST support at all.

Editing

If creating new records or editing existing record dates, the dates will be interpreted as in the selected time zone.

If you want to create new records with dates that either should be interpreted as local system time zone or from any other time zone, specify the timeZone field on the record.

Saving

When saving or syncing data, the dates will be restored to local system time and converted to JSON ISO formatted. When restoring, it adds or subtracts the time difference accordingly. For instance, if the current timezone is UTC and you're in UTC +3, 3 hours will be added to the time.

The store.toJSON() and model.toJSON() methods also restores the data. For example, eventStore.toJSON() will show the dates in local timezone.

Has a corresponding runtime timeZone property.

Specify true to automatically call load method on the next frame after creation.

Called on the next frame to allow a Scheduler (or similar) linked to a standalone CrudManager to register its stores before loading starts.

Sets the list of stores controlled by the CRUD manager.

When adding a store to the CrudManager, make sure the server response format is correct for load and sync requests. Learn more in the Working with data guide.

Store can be provided by itself, its id or as a store descriptor.

Has a corresponding runtime crudStores property.

Set to false to only include the id of a removed parent node in the request to the backend (also affects programmatic calls to get changes etc.), and not the ids of its children.

Consider the following scenario, removing parent 1:

{
  id : 1,
  children : [
    { id : 11 },
    { id : 12 }
  ]
}

With includeChildrenInRemoveRequest : false, the backend will only receive the removal of id 1.

With includeChildrenInRemoveRequest : true (the default), the backend will receive the removal of id 1, 11 and 12.

Name of a store property to retrieve store identifiers from. Make sure you have an instance of a store to use it by id. Store identifier is used as a container name holding corresponding store data while transferring them to/from the server. By default, id property is used. And in case a container identifier has to differ this config can be used:

class CatStore extends Store {
    static configurable = {
        // store id is "meow" but for sending/receiving store data
        // we want to have "cats" container in JSON, so we create a new property "storeIdForCrud"
        id             : 'meow',
        storeIdForCrud : 'cats'
    }
});

// create an instance to use a store by id
new CatStore();

class MyCrudManager extends CrudManager {
    ...
    crudStores           : ['meow'],
    // crud manager will get store identifier from "storeIdForCrud" property
    storeIdProperty  : 'storeIdForCrud'
});

The storeIdProperty property can also be specified directly on a store:

class CatStore extends Store {
    static configurable = {
        // storeId is "meow" but for sending/receiving store data
        // we want to have "cats" container in JSON
        id              : 'meow',
        // so we create a new property "storeIdForCrud"..
        storeIdForCrud  : 'cats',
        // and point CrudManager to use it as the store identifier source
        storeIdProperty  : 'storeIdForCrud'
    }
});

class DogStore extends Store {
    static configurable = {
        // storeId is "dogs" and it will be used as a container name for the store data
        storeId : 'dogs',
        // id is set to get a store by identifier
        id      : 'dogs'
    }
});

// create an instance to use a store by id
new CatStore();
new DogStore();

class MyCrudManager extends CrudManager {
    ...
    crudStores : ['meow', 'dogs']
});

When true the Crud Manager does not require all updated and removed records to be mentioned in the sync response. In this case response should include only server side changes.

Please note that added records should still be mentioned in response to provide real identifier instead of the phantom one.

An array of store identifiers sets an alternative sync responses apply order. By default, the order in which sync responses are applied to the stores is the same as they registered in. But in case of some tricky dependencies between stores this order can be changed:

class MyCrudManager extends CrudManager {
    // register stores (will be loaded in this order: 'store1' then 'store2' and finally 'store3')
    crudStores : ['store1', 'store2', 'store3'],
    // but we apply changes from server to them in an opposite order
    syncApplySequence : ['store3', 'store2', 'store1']
});

Has a corresponding runtime syncApplySequence property.

Configuration of the AJAX requests used by Crud Manager to communicate with a server-side.

transport : {
    load : {
        url       : 'http://mycool-server.com/load.php',
        // HTTP request parameter used to pass serialized "load"-requests
        paramName : 'data',
        // pass extra HTTP request parameter
        params    : {
            foo : 'bar'
        }
    },
    sync : {
        url     : 'http://mycool-server.com/sync.php',
        // specify Content-Type for requests
        headers : {
            'Content-Type' : 'application/json'
        }
    }
}

Since the class uses Fetch API you can use any of the Request interface options:

transport : {
    load : {
        url         : 'http://mycool-server.com/load.php',
        // HTTP request parameter used to pass serialized "load"-requests
        paramName   : 'data',
        // pass few Fetch API options
        method      : 'GET',
        credentials : 'include',
        cache       : 'no-cache'
    },
    sync : {
        url         : 'http://mycool-server.com/sync.php',
        // specify Content-Type for requests
        headers     : {
            'Content-Type' : 'application/json'
        },
        credentials : 'include'
    }
}

An object where you can set the following possible properties:

This config validates the response structure for requests made by the Crud Manager. When true, the Crud Manager checks every parsed response structure for errors and if the response format is invalid, a warning is logged to the browser console.

The config is intended to help developers implementing backend integration.

By default, if an event handler throws an exception, the error propagates up the stack and the application state is undefined. Code which follows the event handler will not be executed.

Set this to true to catch exceptions thrown by this object's event handlers and continue processing the event. The exception will be rethrown on a zero millisecond timeout, so it will not destroy the stack.

Has a corresponding runtime catchEventHandlerExceptions property.

Project data as a JSON string, used to populate its stores.

const project = new ProjectModel({
    json : '{"events":[...],"resources":[...],...}'
}

Has a corresponding runtime json property.

Specifies the output format of toJSON.

• inlineData - Return all crud store data, plus this project fields (under the project key). For example:

{
    "project" : {
        "startDate"    : "2024-03-22",
        "endDate"      : "2024-04-22",
        "hoursPerDay"  : 8,
        "daysPerWeek"  : 5,
        "daysPerMonth" : 20
    },
    "events"             : [...],
    "resources"          : [...],
    "assignments"        : [...],
    "dependencies"       : [...],
    "resourceTimeRanges" : [...],
    "timeRanges"         : [...]
}

• model - Return only the project fields. For example:

{
    "startDate"    : "2024-03-22",
    "endDate"      : "2024-04-22",
    "hoursPerDay"  : 8,
    "daysPerWeek"  : 5,
    "daysPerMonth" : 20
}

If set to true, or a config object, this makes the CrudManager load records only when needed. When a record or a date range that is not already loaded is requested, a load request will be made to the specified URL. More more details about lazy loading, see the guide

Has a corresponding runtime lazyLoad property.

If set to true, this makes the CrudManager load pages of data, instead of loading the complete dataset at once. The requests made to the loadUrl will contain params with info about the current dataset being requested:

• page - The resource page
• pageSize - The resource page size
• startDate - The start date of the calculated timespan
• endDate - The end date of the calculated timespan

For more details about paging, see the guide

When the CrudManager/Project is configured with lazyLoad set to true, you can configure your own data fetching logic by implementing this function. Doing this will override the built-in fetching mechanism using the loadUrl.

When implementing this, it is expected that what is returned is an object fulfilling the contract of a regular CrudManager/Project load call.

An object where property names with a truthy value indicate which events should bubble up the ownership hierarchy when triggered.

const container = new Container({
    items : [
       { type : 'text', bubbleEvents : { change : true }}
    ],

    listeners : {
        change() {
            // Will catch change event from the text field
        }
    }
});

Set to true to call onXXX method names (e.g. onShow, onClick), as an easy way to listen for events.

const container = new Container({
    callOnFunctions : true

    onHide() {
         // Do something when the 'hide' event is fired
    }
});

Has a corresponding runtime callOnFunctions property.

This config manages DST correction in the scheduling engine. It only has effect when DST transition hour is working time. Usually a DST transition occurs on a Sunday, so with non-working weekends the DST correction logic is not involved.

If true, it will add/remove one hour when calculating end date. For example: Assume weekends are working and on Sunday, 2020-10-25 at 03:00 clocks are set back 1 hour. Assume there is an event:

{
    startDate    : '2020-10-20',
    duration     : 10 * 24 + 1,
    durationUnit : 'hour'
}

It will end on 2020-10-30 01:00 (which is wrong) but duration will be reported correctly. Because of the DST transition the SchedulerPro project will add one more hour when calculating the end date.

Also this may occur when day with DST transition is working but there are non-working intervals between that day and event end date.

{
    calendar         : 1,
    calendars    : [
        {
            id           : 1,
            startDate    : '2020-10-26',
            endDate      : '2020-10-27',
            isWorking    : false
        }
    ],
    events       : [
        {
            id           : 1,
            startDate    : '2020-10-20',
            endDate      : '2020-10-30'
        },
        {
            id           : 2,
            startDate    : '2020-10-20',
            duration     : 10 * 24 + 1,
            durationUnit : 'hour'
        }
    ]
}

Event 1 duration will be incorrectly reported as 9 days * 24 hours, missing 1 extra hour added by DST transition. Event 2 end date will be calculated to 2020-10-30 01:00, adding one extra hour.

If false, the SchedulerPro project will not add DST correction which fixes the quirk mentioned above. Event 1 duration will be correctly reported as 9 days * 24 hours + 1 hour. Event 2 end date will be calculated to 2020-10-30.

Also, for those events days duration will be a floating point number due to extra (or missing) hour:

eventStore.getById(1).getDuration('day')  // 10.041666666666666
eventStore.getById(1).getDuration('hour') // 241