Page History
...
Code Block | ||||
---|---|---|---|---|
| ||||
{ "name": "packagename-componentname", // String "displayName": "more descriptive name that is shown in the designer", // String "version": the component version (integer) "icon": "A reference to the icon shown in designer" , "preview": "A reference to the preview gif to be displayed" , "definition": "A reference to the js file that implements this component's in the browser", "serverscript": "[optional] A reference to the js file that implements this component's server-side logic, if any.", "doc": "[optional] A reference to the js file that contains the jsdocs of the component api, or ifmodel anyproperties.", "group": true // default true, so the definition file can be grouped when creating the .war file for deployment "deprecated": "This component will be replaced in the next versions.", // (optional) some string to mark the component as deprecated - if it is deprecated "replacement": "package-compname", // (optional) in case of deprecation, developer will provide a quick fix for such components to be automatically changed to the given replacement component // (make sure they have compatible .spec defined; in most cases this is useful when moving components from a package to another package or when // rewriting a component but keeping it's contract unchanged) "libraries": /* Array of js/css definitions (which are JSON objects with 'name'-the lib name, 'version'-the lib version, 'url'-the lib url, 'mimetype'-the lib mimetype, one of 'text/javascript' or 'text/css', 'group' - give false here when this lib dependency should not be grouped when exported as .war; default true) that need to be included for this component. */, "keywords": /* Array of keywords used for searching components in the palette. For instance, for the calendar component some appropriate keywords that might be used are: "day", "month", "year"*/, "categoryName": "Advanced", // category for form designer palette; only makes sense for components, not services "model": { "property1Name": /* type description (optionally including optional default value and others) */, "property2Name": /* type description (optionally including optional default value and others) */ }, "handlers": { "handler1Name": { /* handler function type definition*/ }, "handler2Name": { /* handler function type definition*/ } }, "api": { "apiFunction1Name": { */ api function signature description json*/ }, "apiFunction2Name": { */ api function signature description json*/ } }, "internalApi" : { "internalApiFunction1Name": { */ internal api function signature description json*/ }, "internalApiFunction2Name": { */ internal api function signature description json*/ } }, "types": { "customType1Name": { "subProp1Name": /* type description" */, "subProp2Name": /* type description" */ }, "customType2Name": { "subProp1Name": /* type description" */, "subProp2Name": /* type description" */ } } } |
...
Documentation for properties can be added to each property's definition via the "tags" section using key "doc" or in the doc file using a variable with same name as the property.
Code Block | ||
---|---|---|
| ||
/** * some desciption * @example elements.%%elementName%%.yourName = 'myname' */ var yourName; |
The description that you provide in the .spec file will be used in Servoy Developer as:
...
Overview
Content Tools
Activity