Page History

...

For performance reasons (and security) the spec file of a webcomponent should tell us what property should (and can) be send sent to the server.

This page: Specification under Data synchronization we list the values the pushToServer attribute of a model property can have. By default the property is not allowed to be pushed to the server and therefor therefore also not watched (by an angular $watch). Besides that you can also specify "allow" this also means that we don't add a watch on it, but the component pushes the value itself when it knows that it is changed. Dataproviders with the auto-apply directive work like that (Provided directives, filters and model values). Then the auto-apply directive will push data when the directive is triggered (dom onchange event). Components can also use the servoyApi.apply("dataprovider_propertyname") when the need to program it out. Using the above will not result in a loss of performance.

If you do want other properties to be send sent to the server because you want to access them in scripting you can use one of the 2 values "shallow" or "deep". Shallow is quite cheap that just a reference check, but when you have a complex object that has properties (or an array) which doesn't change itself but it changes the content (sets a property of that object) then you need to use "deep". This has a performance penalty because angular now needs to create a copy of the original object and compare all the time the full structure of that object. This is not a problem when there are only a few on one page but if if you have many of them, for example in a portal like component, then this can count up.

...

Object.defineProperty($scope.model,$sabloConstants.modelChangeNotifier, {configurable:true,value:function(property,value) {
				switch(property) {
					case "borderType":
						$svyProperties.setBorder(element,value);
						break;
					case "background":
					case "transparent":
						$svyProperties.setCssProperty(element,"backgroundColor",$scope.model.transparent?"transparent":$scope.model.background);
						break;

You need to include the $sableConstants $sabloConstants in your component which will have a property "modelChangeNotifier" that property is the name of the function that is then added with a Object.defineProperty call to the $scope.model object.

...

Of course this means that the tableview can't really really be used to directly edit the data, also using readonly textfields and enabling this property is faster then using all labels (because labels are not optimized because on action and so on need to work)

...

• Try to minimize the usage of controller.recreateUI(), Using the solutionModel is not a problem if you use it upfront to make all your forms the way you want. But try to avoid regenerating the forms all the time, this was quite cheap for the SmartClient, was already quite a bit heavier for a WebClient, but for the NGClient it has even more performance implications because quite a bit of logic needs o constantly be pushed to the client (besides a new template)
• Try to avoid a lot of nesting of forms, for example use a portal component instead of tabpanel that has a tableview form again. Or using a form for just a toolbar that could be quite an easy component.
• Try to avoid to avoid touching elements or forms when you are not (planning to) show them. Setting properties is not a problem, but calling api on an element of a form that is not shown means that we have to quickly create it (in a hidden div) so that the element is really alive.

...