...

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

...

$services.callServerSideApi("myservicename","loadRelatedFoundsetForNewTreeNode",[rows[i], 2]).then(function(returnedFoundsetRef) {
   console.log("Related foundset successfully returned...");   
 });

Internal API can also be used for API that is defined on client, but can only be called from server side scripting. This API shouldn't be called from Servoy Developer scripting and won't show in code completion.

Calling handlers from server-side js

Since Servoy 8.3 server side scripting also has access to the handlers a developer has assigned in the designer - through $scope.handlers. Together with the new "private": true configuration on a handler definition in the spec file, you can make handlers that are not directly callable from the client but only through server side scripting.

...

var query = servoyApi.getQuerySelect(foundset.getDataSource());

getMediaUrl is used to generate a url from a byte array so that the client can get the bytes from that url (available starting with Servoy 2019.09)

var query = servoyApi.getMediaUrl(bytes);

getDatasourcePKs is used to generate a list of primary keys names for the given data source (available starting with Servoy 2021.06)

var query = servoyApi.getDatasourcePKs(datasource);

Logging

Inside the server side scripting file of a component/service you can log messages using " console ", not application,output. The output will appear in developer's console view as well as in the application server log file (depending on configured logging levels). For example:

console.log(message);
console.warn(message);
console.error(message);

Hooking up into component lifecycle

Support has been added in Servoy 2022.06 for two new handler functions. These can be defined for hooking up into the component's client side destroy / create lifecycle.
These two methods will be called directly in server-side scripting when the component is shown/hidden on client. They are useful because - for example - some components want to do cleanup actions when they get hidden - but it is too late to call a server-side api when the component detects that it is destroyed on client, because server will normally block that call - the form is already known to be hidden (sometimes, in rare cases, at that point it may even be destroyed).

Any code the component wants to execute server-side for show/hide can be added to these two functions by:

• defining them in the server side scripting file of the component

  onShow: which will be called every time the component gets shown

  Code Block
  language js
  $scope.onShow = function() { // code to execute when the component is shown/created in the client. }

  onHide: which will be called every time the component gets hidden

  Code Block
  language js
  $scope.onHide = function() { // code to execute when the component is hidden/destroyed in the client. }

  
  

• defining them in the internalApi section of the component's .spec file:

  Code Block
  language js
  "internalApi": { "onHide": {}, "onShow": {} }