A component or service can have a serverside part, so logic is executed on the server, in the spec file this is configured like:

...

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 $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 $scope.xyz()).

Server-side code is build up the same as the client-side so you have $scope object with model and /api and /(since 8.3) handler/(since 8.3.1) servoyApi objects. On that

An example is the default tabpanel.

API methods (private, public) and calling them in client-side js, server-side js and solution code

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

An example is the default tabpanel.

What can also be done (Servoy 8.0.2+) is that clientside scripting can call the server part. These function has to be defined on the $scope object, as an example:api methods.

Private and public API methods can be defined either in server side js code or in client side js code. Solution code can call public API methods from either of the two. Server-side js code can call client side js (and of course server side js) public and private API methods. Client side code js can call server side private API methods (and of course any client side API methods).

Calling client side API methods from server side js

$scope.api.mycallbackclosePopup = function(name,type) {
	return "something";
}

For information about documenting API functions see the documenting api functions example. For information about documenting model properties and handlers please have a look at Documenting what properties do / Documenting handlers and handler templates.

) // 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 in "api" section of the spec file; so it's public
	}
}

Calling server side internal API methods from client side js

What can also be done (Servoy 8.0.2+) is that client-side scripting can call a server side component/service private/internal scripting method. This function has to be defined on the $scope object in server-side js. Since Servoy 8.2 you must also define these functions methods in a special Api api category of the .spec, internalApi. In prior versions define these in api section instead. As an example:

"internalApi":
	{
		"mycallback" :{
			"returns": "string",
	         "parameters":[
	$scope.loadRelatedFoundsetForNewTreeNode = function(parentRecord, relationIdx) {
    (...) // related foundset is prepared here
	return newRelatedFoundset;
}

"internalApi": {
    "loadRelatedFoundsetForNewTreeNode": {
     				{ 						  "returns": "foundsetRef",
        "nameparameters":"name", [
						        {   "name": "parentRecord", "type": "string"
					           record" },
					            {
						            "name": "typerelationIdx",
						            "type": "string"
						        }
	int" }
        ]
  			 ] 		}
	}

then Then a component can use the servoyapi svyServoyapi to call this server side internal/private function from client side js:

  // assign to the scope the svy-servoyapi
  scope: {
    	  model: '=svyModel',
		    servoyApi: '=svyServoyapi'
 
    },
 
	// in the controller or link functions you can use that then
    (...)
    $scope.servoyApi.callServerSideApi("mycallbackloadRelatedFoundsetForNewTreeNode",["test"rows[i], "1"2]).then(function(retValuereturnedFoundsetRef) {
        console.log(retValue"Related foundset successfully returned...");
     });

...

}, (...));
    (...)

callServerSideApi above needs to have the function name and an array of arguments, ; it returns a $q promise of angular where the then function will give you the return value of the callback.

For In case of a service you can use the $services service to do the same thing. the only thing extra is that , but you have to also give the servicename itselfname of the service itself (of course usually services would not work with foundsets and relations, but it is just an example):

$services.callServerSideApi("myservicename","mycallbackloadRelatedFoundsetForNewTreeNode",["test"rows[i], "1"2]).then(function(retValuereturnedFoundsetRef) {
   console.log(retValue"Related foundset successfully returned...");    
 });

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.

$scope.mycallbackmyServerSideInternalAPIMethod = function(name, type) {
    // call a hanlderhandlder directly with the arguments are return the value the handler gives
	return $scope.handlers.onAction(name, type);
}

Private handlers which are callable only serverside from server-side js can be used to implement secure complex web components; for instance a Navigation Menu component which has a collection of MenuItems custom type. When the whole menu is disabled you can use the protecting properties (see Protecting Properties at Specification (.spec file)) to block certain handlers to be triggered; however when a single MenuItem is disabled and the navigation menu is enabled meanwhile, to securely prevent the handler to be executed for the disabled MenuItem (e.g. onMenuItemClick should be executed only if the menu item is enabled), you should call a server side script which verifies the MenuItem is actually enabled and triggers the private handler from the server side script.

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);

Servoy API

For information about documenting API functions see the documenting api functions example. For information about documenting model properties and handlers please have a look at Documenting what properties do / Documenting handlers and handler templates.

Calling special servoyApi functions from server-side js

Starting with Servoy 8.3.1, inside the server side scripting file of a component/service you can call specific api Servoy provided functions using object the "servoyApi" object.

hideForm api  is used to mark a form as not visible anymore immediately because cannot wait for client to mark it as hidden(for example in removeTab of a tabpanel). 

...

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

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);