Page History

...

It is recommended to have a the suffix "services" as the in your service package name. (for example default servoy services are found into "servoyservices" directory) . To - to avoid naming collisions between components component and services service packages. Furthermore, in order to avoid naming collisions among sevices services themselves, a new service name should adhere to the same naming convention as WebComponents.

A service can get it's client side scope from the $services angular service/factory that the system provides. On that factory you can ask for the service scope: 

    $services.getServiceScope(serviceName);

This returns an angular $scope instance, ; that one holds an a model property that is the javascript object that is synced kept in sync between server and client (just as it happens for a webcomponent). Also that That scope instance can also be used to watch add watches on its own properties , - so that the service can interact with state changes from the server. This is for example very handy if the service must interact with a browser refresh, ; then the state is transferred over to the client and the service should use the model state of the scope to reconstruct it's behavior. This is done Watches can be added in an angular run function that is executed when the browser page loads.

When a service scope (the model object) is changed through by a server push-to-client, or when a service api function is called, the system will call the angular $digest() function on the scope object of the service. This way all the watches that are on that service scope will be evaluated by angular. If your service is can be used throughout the whole page , - so webcomponents are using your service to get state from it (webcomponent do have watches on your service) then you have to make sure that you call the rootScope digest so that a full digest cycle will happen:

    if (!$rootScope.$$phase) $rootScope.$digest();

The if is for checking if there is already a digest cycle happening, else you call the $rootScope $digest method so that all the watches of the page are evaluated and webcomponents or other services that have watches on your state will see the change.

Services can also have service server side api - just like webcomponents, The same kind of object structure is then also provided, so there is a $scope object which has a model property that is the object that is synced between server and client.

...

From scripting, when calling plugins.testservice.talk() it should execute the service talk method. The service model is automatically synchronized with the server. In order to observe server side modifications the service must add a watch to the service state.

A service can have a method called "cleanup" that will be called when solution is closed in order to clear its state.

...