A (WYSIWYG) form designer needs component meta data to be able to handle components. This meta data is expressed in a specification.
A simple metadata specification is expressed in json format. (called the .spec definition file)
The specification defines:
identifier information (component name, icon, display name, ...)
Name convention: the provided string is of the form package name, followed by a dash sign ('-'), followed by the component name. The package name is the name of the package the component is part of, and component name is simply the name of the component. Both package name and component name should be written in lower-case.
In a json format:
Starting with 8.2 (before these were defined in "api") there is also the internalApi section that is better described in Server Side Scripting page (calls between client and server that are only meant for the code inside the component/service to use).
You can find an example .spec file below.
The "group" property on the top level spec or in the libraries section tells Servoy if that the definition or library can be grouped or not; by default this is allowed. This is used when a WAR is generated by the WAR Exporter.
The "group" property
The libraries which contain references to external files cannot be grouped because in the deployed applications the relative paths to those resources are lost, therefore the components will not work.
Such libraries are font-awesome.css or tinymce.js, they should always have "group": false in the specification file of the components that use them.
A component/service/layout can be marked as deprecated by using the "deprecated" and/or "replacement" properties.
The deprecated components/layouts will not be shown anymore in the palette.
The deprecated services will not be shown anymore under the Solution Explorer plugins node. Markers will be added in case they are used in scripting.
The following combinations are possible:
In the case when the "replacement" property is used (supported for component level deprecation only), the generated markers for the used deprecated components will also have a quick-fix.
Using only the "replacement" property will also mark the component as deprecated, and the generated marker will have a quick-fix.
The "deprecated" property
The "deprecated" property can also be used to deprecate service/component api or properties:
e.g. service function
e.g. component property
In this case, the deprecated property will not be shown in the properties view.
A ng web component or ng service specifies all its properties and the type of each property in the model section of the .spec file.
Apis or handlers are not supported under "model" or "types" because these are just meant as container objects that transmit data/information between the component/service and the server.
For giving types of each property you can use any of the default provided property types that you can find here as well as any custom types defined in the "types" section. Arrays are also allowed (append "" to the type name).
Property types under model can be defined in two ways:
simply by specifying it's type:
with additional configuration options if you want/need to tell Servoy more about how this property should be treated (this is just a sample, all configuration options are optional and each one will be detailed later); "type" is mandatory.
To define an array property just append "" to the type name.
To specify configuration options for each element of the array you can do:
For more information on array types see the array property types page.
types section defines custom internal types that can then be used by this web component/service for one or more of its properties in the model as well as for parameter and return value types defined in other sections. (for example a tabpanel component has a "tab" type that describes one tab inside the tab-panel). Custom type definitions each support for defining subproperties whatever is supported under model. For example:
For more information on custom property types and how they work see the custom object property types page.
There is a set of standard configuration options and each specific property type (for more advanced types like "foundset", "dataprovider", ...) can have some extra configuration options that are detailed by each type.
Stardard tags are the ones that control data synchronization, tags and default/initial/predefined values.
Data modifications are automatically propagated from server to client.
For performance (and security) reasons, data modifications from client to server are not propagated by default. To enable this configure pushToServer setting on the property.
|reject||this is the default, no data synchronization from client to server for this property|
|allow||data changes from client to server are allowed|
|shallow||same as allow, but sablo will also add a watch on the model (in the client) and send changes to the server; the watch is based on object reference/primitive value (more performant, but in case of structured/nested objects it will only trigger data synchronization when the objects are different by reference, even if they are actually 'equal' by content)|
same as allow, but sablo will also add a watch on the model (in the client) and send changes to the server; the watch is based on object equality (compares old and new values of structured/nested objects, less performant because it keeps and compares two copies of structured/nested objects); "deep" is mostly meant to be used for properties of type 'object' - that can contain nested JSON - and that for any change (doesn't matter how little) will send over the complete value to the server.
Note that in Servoy, data-provider property changes are sent to server using svy-apply (servoy api call) and svy-autoapply (directive); for these to work properly, these properties should set pushToServer to allow. Otherwise those data provider properties will be read-only.
Properties can be configured with special tags that may be interpreted by the deployment and/or development environment.
Supported tags are: scope, addToElementsScope, logWhenOverMax, allowaccess, directEdit, useAsCaptionInDeveloper + captionPriority, showInOutlineView, main and mode.
scope: Restricts the model property to: 'design', 'runtime' or 'private'.
Design means property can only be assigned from designer (not from scripting). Runtime means the property cannot be assigned from designer (will be hidden in Properties View). Private is an internal property, that should only be used by component itself (so component.js or component_server.js). Will not show in Properties View and cannot be assigned from scripting.
addToElementsScope : boolean
For component type, specify whether component should be added to elements scope. Default is false, so component can be accessed only via component property. If true, will be accessible like any other element of the form.
For the valuelist property type. If set to false, no logging will be done when only sending "max" number of items to the browser even though the valuelist does contain more than "max" items. Default is true.
allowaccess: string or array of strings
This tag can define if an edit (sent from browser to server) of this property is allowed even if properties such as "visible" or "enabled" (of the component or parent form) are false. By default, if the visibility of a component or its parent form is false, Servoy doesn't allow the modification (coming from browser) of any other property (it blocks it and logs it on server). With this tag you can say for a property that changing it should be allowed even in these situations; for example on "size" property you could say: I allow it for "visible"; or for both: ["visible", "enable"]
One property of a component can be tagged as directEdit for designer, this way that property can be edited directly by double clicking the component (for example text property on label/button).
useAsCaptionInDeveloper : boolean and captionPriority : integer (> 0) (starting with Servoy 8.3)
Can be used to provide a caption for Custom Object Types in developer based on the value of a subproperty. For example if you create a table component that defines in .spec custom object types (that could also be "droppable" in developer) for columns, you might want to show as caption in developer for each such 'column' the header text subproperty value or - if that is not set - the dataprovider subproperty value. The captionPriority tag will allow you to specify in which order subproperties are checked for non-empty string values for the caption. That caption text ends up visible in places such as the outline view or in form designer for each column. You would specify it like this:
showInOutlineView: boolean (for Servoy < 8.3)
In the Outline View, Custom Type objects have the name of the type as lables. The showInOutlineView:true tag can be added to any property definition in order to append the design time value of that property to the label of the custom type object in the Outline View. If you are using Servoy >= 8.3 please use "useAsCaptionInDeveloper " and "captionPriority" instead. Starting with that version "showInOutlineView" : true is equivalent to "useAsCaptionInDeveloper" : true.
main: boolean (starting with Servoy 8.4)
Used only for dataprovider types. In case there are more then one dataprovider types, setting this tag to 'true' will define the main dataprovider, that
is needed on different places, like sorting. As an example, having a component with 2 dataprovider properties, and using it in a table view, that
component is used for column rendering, and calling sort on that column, by clicking on the column header, will need the dataprovider from the
component to do the sort - using the 'main' tag, we can define the dataprovider to use. (see onrenderlabel component from servoy-extra package)
mode: string (starting with Servoy 2019.03) - Restricts the model property to: 'combobox' or 'typeahead' in developer properties view. (Default is combobox)
This can be used only on string properties when they have "values" attribute. Setting mode to typeahead will create a typeahead property in property editor. Setting mode to combobox or skipping mode property will create a combobox in property editor.
A property can have a "default" value like:
But this would mean that restore to default or empty the property would always set that default property back. This is wanted behavior if the property has to have some default value like if a property must be 1 of a few values and the default is one of those.
If a property should allow the developer to choose in the properties view from a predefined set of values you can use the "values" attribute in combination with "default" and optionally "mode" tag (see above) (default can be one of the predefined values but can also be something else):
But for a button or label in which you initially want some text, but reverting should really clear the text, the default value is not really usable (the label text should be able to be nothing, in case only an image is meant to be shown in that label). For this we have the attribute "initialValue":
This is like a constructor value, set only once when the component is added.
Components can be protected using two special security types: visible and protected.
For example. when a component is made readonly from the server the component will make the its UI non-editable. However, a malicious client could still send json messages to the server and update data; that is what this properties avoid server-side.
Similarly, when a form or component is marked invisible, its data should not be sent to the client since it may contain sensitive data.
More information about how these properties work with containers can be found here.
Protecting properties (of type
protected)are used to protect an entire component or specific properties or handlers.
When the property is blocking no changes or function calls from the client are accepted.
For example, the
editable property as defined below will be true by default, when set to
false changes from the client to the component will be rejected. Also functions cannot be called from the client.
Protection can be done for specific properties or functions.
In this example, when
protectCustomer is set to
customerAddress can still be changed the the client, but
removecustomer are protected.
Protecting properties themselves can never be modified from the client.
You might also want to read about how protecting works with containers below.
Visibility properties (of type
visible) are similar to protecting properties. They are protecting the component and also hide the data from the client if the component is not visible.
In this example, a component's model can be filled with a customer name, but when the property
visible is set to
false, the component will be protected and the data will not be sent to the client. When
visible is set to
true, data not sent before will be pushed to the client.
Visibility properties themselves can never be modified from the client.
You might also want to read about how visibility works with containers below.
Protecting and visibility properties on containers will protect the container and also components inside the container
For example forms are containers and the visibility of a form will protect the components inside it as well. So only when server side makes a form visible or a web component (container) from the browser asks that it wants to make a form visible (via servoyApi.formWillShow, provided it does have access itself to that form) that form will be accessible to the browser. Container-like web components can only make forms visible if they have those forms referenced in their (sub)properties (so basically server-side gave them access to be able to make those forms visible).
Similarly to properties of type
visible , the properties of type
enabled are also protecting properties, so they can never be modified from the client.
It is important to use type
enabled if we want the value from the parent container (i.e. form, portal) to be pushed to the component. For instance if a portal is disabled, then all the components from the portal which have a property of type
enabled will also be disabled.
Servoy has 2 special controller/foundset based properties where a component also can be notified for.
controller.readOnly = true in the developer will set this boolean to a property called "readOnly" of a webcomponent, this property should be a runtime or even a hidden property. It should not be a design time property, because the system can set it at any time (to true or false).
If you want also a design time property to control the editable state then add a second property, see example below, and then having a tag in the template like: ng-readonly="model.readOnly || !model.editable"
With this property a component can do its thing to set or unset the readonly mode for itself.
It's better to have type this property as "protected" because it should only be able to change at the server, never from the client.
See as an example our bootstrap textbox: https://github.com/Servoy/bootstrapcomponents/tree/master/textbox
findmode is a special type: Findmode property type which can be used to set all kind of other properties which are normally protected from changing on the client side. Or you can just use it as a type for any property you want:
When the find mode changes the boolean value of your property will also change. This way you can react to a form/foundset going into find mode. Like resetting a specific format, allowing any kind of input.
The function description in the handlers section can be just "function" or a more complex type describing the arguments and return type
the private configuration makes the handler only accessible through Server Side Scripting. But not by the client/browser itself.
This section defines the signatures and behaviors of functions that can be called from the solution on this component/service.
The signature description json for functions in the api section describes the arguments, type of call and return type, For example:
The implementation of such api functions can be located either in the browser-side component/service logic implementation ("definition" in .spec file) or in the server-side component/service logic implementation ("serverscript" in .spec file)
There are several types of api calls described below.
About calling browser-side api functions of components
When a component (not service) api function that the solution can call is implemented in browser-side component/service logic implementation ("definition" in .spec file) it is important to note that calling such a function when the form of that component is not shown will result in a temporary "force-load" of that form in a hidden div in the browser - just to be able to call that api function. As this is usually not useful and will slow-down the solution due to the hidden loading of a form, this situation should be avoided (either by the solution or, where possible, by using delay until form loads async api functions).
This is the default type of api function; the example above is a sync api function definition. Sync functions will call the client and wait for the api function to execute/return before continuing. Sync api functions can have a return value.
A special kind of sync api function type is sync functions that do not block event processing. This is not needed - in almost all cases.
It can be defined by adding a "blockEventProcessing" : false (that defaults to true) to the function definition. When it is set to false, Servoy will expect that this API function call will be long-running (so it will not time out if it takes long to execute) and at the same time it will allow other events to be handled by the event dispatcher while waiting for the return value. This is helpful for example if a component would have an API function call like "askUserForSomeValue(someForm, ...)" which shows a modal dialog containing a form and returns a value. That API call has to wait for the return value an indefinite amount of time without blocking other events from being dispatched. Example:
Async api calls will allow the calling code to continue executing and will execute the api call later/decoupled.
Async api functions cannot return a value.
There are 3 types of async calls.
Simple async calls - when called from solution (server) code - will get executed in browser later, when current request to server is done.
Just add "async": true (another optional parameter (that by default is false)) to the call definition; it means the client side api is not called right away, but at next message sent to the client.
These are currently supported only for ng services, not components. These are async functions that will be called in browser right away (rather then when the current request to server is done), but the code that calls them does not wait for them to finish execution before proceeding.
They are useful when for example you want to send progress information to the service client-side while executing a long-running-operation server-side.
Just add "async-now": true (another optional parameter (that by default is false)) to the call definition.
These are special types of async calls meant only for components, not services. These functions, when called, will execute later (similar to simple async, when a request to server is done executing) but only if the form is loaded inside the browser.
If the form is not loaded inside the browser they will wait for the form to get loaded (shown by solution somewhere) before being executed.
You can use these to avoid accidental calls from the solution to execute the api function without the solution intending to show the form. The difference compared to simple async functions is that simple async functions will load the form - if not already loaded in browser - in a hidden div just in order to execute the api call... this can be time-consuming and is usually not needed (a form that is not shown just being loaded and discarded in order to call an async function).
Just add "delayUntilFormLoads": true (another optional parameter (that by default is false)) to the call definition. This flag was also known previously as "delayUntilFormLoad" (but that is now deprecated).
This extra-flag only makes sense in combination with either "async" or "delayUntilFormLoads". Does not make sense for sync or async-now functions.
Calls to async functions with the same name and marked as "discardPreviouslyQueuedSimilarCalls" that come in before previously queued such calls are really sent to the browser window will discard those previous calls completely (and keep only the latest).
So for example a requestFocus() function call you would only need to send once - after an event handler finished execution server-side. You can send that later and only for the last requestFocus() that executed. If you click on a button for example and the solution has very complex code executing there that ends up calling requestFocus() 100 times on various components from various forms, you actually only want the last requestFocus to execute after the button is clicked. Otherwise there would be a huge performance penalty. That is why all requestFocus calls from existing components are (or should be) marked as "discardPreviouslyQueuedSimilarCalls".
Just add "discardPreviouslyQueuedSimilarCalls": true (another optional parameter (that by default is false)) to the call definition. This flag was also known previously as "globalExclusive" (but that is now deprecated).
A component or service can have a server-side part as well (optional); this logic is executed directly on the server; in the spec file this is configured like:
See Server Side Scripting for more info about server side scripting.
Web Components are organized in component packages. The palette of the WYSIWYG editor shows components grouped by package name. To further group components from the same package, the property 'categoryName' can be used. 'categoryName' is a property that each component can specify in its spec file. The palette then displays components belonging to the same category grouped under the specified 'categoryName'.
As an example we could have a Tab Panel that has a definition like: (note: this example does not contain the entire Tab Panel spec)