Child pages
  • Specification (.spec file)

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Code Block
languagejs
titlespec file definition
{
	"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.",

    "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" */
       }
    }
}

...