Page History
...
Code Block | ||||
---|---|---|---|---|
| ||||
Object.defineProperty($scope.myComponentProperty.model, $sabloConstants.modelChangeNotifier, { configurable: true, value: function(property,value) { switch(property) { case "borderType": (...) break; case "background": case "transparent": (...) break; (...) |
Advanced usage of non-foundset-linked components
...
Code Block | ||
---|---|---|
| ||
childElement: { "componentDirectiveName": "servoydefault-textfield", "name": "shipname", "forFoundsetfoundsetConfig": { "recordBasedProperties": ["dataProviderID"] }, "model": { "enabled": true, "text": "Ship Name", "visible": true, "tabSeq": 0, (...) }, "modelViewport": [{ "_svyRowId": ".null;5.10643;_0", "dataProviderID": "Alfreds Futterkiste" }, { "_svyRowId": ".null;5.10692;_1", "dataProviderID": "Alfred's Futterkiste 2" }, (...)] "handlers": { "onActionMethodID": function(args, rowId), (...) }, "api": { "getSelectedText": function(), (...) }, "servoyApi": { "startEdit": function(propertyName, rowId), "apply": function(propertyName, componentModel, rowId) }, "addViewportChangeListener": function(listener), "removeViewportChangeListener": function(listener) } |
...
Code Block | ||||
---|---|---|---|---|
| ||||
{ $foundsetTypeConstants.NOTIFY_VIEW_PORT_ROWS_COMPLETELY_CHANGED: { oldValue : ..., newValue : ... }, // if we received add/remove/change operations on a set of properties from modelViewport // corresponding to a record this key will be set; as seen below, it contains "updates" which // is an array that holds a sequence of granular update operations to the viewport; the array // will hold one or more granular add or remove or change operations; // // BEFORE Servoy 8.4: all the "startIndex" and "endIndex" values below are relative to the viewport's state after all // state after //all previous updates in the array were already processed (so they are NOT relative to the initial // the //initial or final state); indexesof arethe 0 based $foundsetTypeConstants.NOTIFY_VIEW_PORT_ROW_UPDATES_RECEIVED: { // sometimes knowing the old viewport size helps calculate incomming granular updates easier $foundsetTypeConstants.NOTIFY_VIEW_PORT_ROW_UPDATES_OLD_VIEWPORTSIZE: ..., $foundsetTypeConstants.NOTIFY_VIEW_PORT_ROW_UPDATES : [ { type : $foundsetTypeConstants.ROWS_CHANGED, startIndex : ..., endIndex : ... }, { // when an INSERT happened but viewport size remained the same, it is // possible that some of the rows that were previously at the end of the viewport // slided out of it; "removedFromVPEnd" gives the number of such rows that were removed viewport data!). Updates can come in a random order so there is // NO guarantee related to each change/insert/delete indexes pointing to the correct new data in the // final current viewport state // // STARTING WITH Servoy 8.4: all the "startIndex" and "endIndex" values below are relative to the // viewport's state after all previous updates in the array were already processed. But due to some // pre-processing that happens server-side (it merges and sorts these ops), the indexes of update // operations THAT POINT TO DATA (so ROWS_INSERTED and ROWS_CHANGED operations) are relative also to // the viewport's final/current state, so after ALL updates in the array were already processed // (so these indexes are correct both related to the intermediate state of the viewport data // and to the final state of viewport data). // This means that it is now easier to apply UI changes to the component as these granular updates // GUARANTEE that if you apply them in sequence (one by one) to the component's UI (delete, insert and // change included) you can safely use the indexes in there to get new data from the present state // of the viewport. // $foundsetTypeConstants.NOTIFY_VIEW_PORT_ROW_UPDATES_RECEIVED: { // DEPRECATED in // from the end of the viewport due to the insert operation;Servoy 8.4: granular updates are much easier to apply now; see comment above // sometimes knowing the old viewport size helps calculate incomming granular updates //easier NOTE: insert signifies an insert into the client viewport, not necessarily $foundsetTypeConstants.NOTIFY_VIEW_PORT_ROW_UPDATES_OLD_VIEWPORTSIZE: ..., $foundsetTypeConstants.NOTIFY_VIEW_PORT_ROW_UPDATES : [ // an insert in{ the foundset itself; for example calling "loadExtraRecordsAsync" type : $foundsetTypeConstants.ROWS_CHANGED, // on the foundset property startIndex : ..., // can result in an insert notification + bigger viewport size notification, endIndex : ... }, // with removedFromVPEnd = 0 { type : $foundsetTypeConstants.ROWS_INSERTED, // NOTE: insert signifies an insert into the client viewport, not necessarily startIndex : ..., // an insert in the foundset itself; for example endIndexcalling : ...,"loadExtraRecordsAsync" // removedFromVPEndon :the ...foundset property }, // can result in {an insert notification + bigger viewport size notification, // when a DELETE happened inside the viewport// butwith thereremovedFromVPEnd were= more0 rows available in the type : $foundsetTypeConstants.ROWS_INSERTED, // foundset after current viewport, it is possible that some of those rows startIndex : ..., // slided into the viewport; "appendedToVPEnd " gives theendIndex number of such rows: ..., // thatDEPRECATED werestarting appendedwith to the end of the viewport due to the DELETE operationServoy 8.4; it would always be 0 here // NOTE: delete signifies a delete from the client viewport, not necessarilyas server-side code will add a separate delete operation instead - if necessary // a delete in the foundset itself; for example calling "loadLessRecordsAsync"BEFORE 8.4: when an INSERT happened but viewport size remained the same, it was // on possible for some of the foundsetrows propertythat were previously at the end of the viewport // can result in a delete notification + smaller// viewportto sizeslide notification,out of it; "removedFromVPEnd" gives the number of such rows that were // with appendedToVPEnd = 0 // removed from the end of the viewport due to this insert operation; removedFromVPEnd : ... type : $foundsetTypeConstants.ROWS_DELETED}, { startIndex : ..., // NOTE: delete signifies a delete from the client viewport, not necessarily endIndex// : ..., a delete in the foundset itself; for example calling "loadLessRecordsAsync" appendedToVPEnd : ... // on the foundset property } ] } } |
...
// can result in a delete notification + smaller viewport size notification,
// with appendedToVPEnd = 0
type : $foundsetTypeConstants.ROWS_DELETED,
startIndex : ...,
endIndex : ...,
// DEPRECATED starting with Servoy 8.4; it would always be 0 here
// as server-side code will add a separate insert operation instead - if necessary
// BEFORE 8.4: when a DELETE happened inside the viewport but there were more rows
// available in the foundset after current viewport, it was possible for some of those
// rows to slide into the viewport; "appendedToVPEnd " gives the number of such rows
// that were appended to the end of the viewport due to this delete operation
appendedToVPEnd : ...
}
]
}
} |
In Servoy < 8.4, you might find what $foundsetTypeUtils provides useful depending on how you plan on using this listener. Starting with 8.4 granular updates are easier to use and you don't need to process those indexes anymore before using them. See comments above.
Note | |||||||
---|---|---|---|---|---|---|---|
| |||||||
It is important to remove the listeners when your component's scope is destroyed. For example if due to a tabpanel switch of tabs your form is hidden, the component and it's angular scope will be destroyed - at which point you have to remove any listeners that you added on model properties (like the child component property), because the model properties will be reused in the future (for that form when it is shown again) and will keep any listeners in it. When that form will be shown again, it's UI will get recreated - which means your (new) component will probably add the listener again. If you fail to remove listeners on $scope destroy this will lead to memory leaks (model properties will keep listeners of obsolete components each time that component's form is hidden, which in turn will prevent those scopes and other objects that they can reference from being garbage collected) and probably weird exceptions (obsolete listeners executing on destroyed scopes of destroyed components). Example of removing a listener:
|
Runtime property access
Since Servoy 8.0.3 , component type is scriptable. Type can be accessed like:
...