Page History

...

The API call that is executed server-side could for example just update some model properties of the component/service; these will be sent automatically as one thing to the client when the server-side code is done. And then client can detect those model changes. Or server-side code could call directly a client side API method after doing some pre-processing for example. More complex components like tabpanel, grouping girds based on foundsets or services like form popup service heavily rely on server-side implementation both for public APIs (defined in "api" section in the .spec file and present in server-side scripting through as $scope.api.xyz()) and for private implementations details from internalAPIs (defined in "internalApi" section of the .spec file and present in server-side scripting through as $scope.xyz() and in client side scripting in the usual api object).

On the $scope.api object you can define the public api methods that you want to execute server side. The difference - compared to client side structure is that "internalApi"s from .spec file are defined directly on $scope compared to client - where "internalApi"s are defined in the same place as public api methods.

...

$scope.api.closePopup = function() // we define a server side public api method
{
    	if ($scope.model.popupIsShown)
   	{
		 {
        // only calls client side api (which generates network traffic) if it is needed
		$scope.doClosePopup(); //
if "doClosePopup" is defined in "internalApi" section of the spec file; so it's private to the component
		// $scope.api.doClosePopup(); // if "doClosePopup" is defined either in "api" (public) or "internalApi" (private) section of the spec file; soand it's public
	implemented in client side js
    }
}

Calling server side internal API methods from client side js

...