...
Basic plugin anatomy
A plugin is a simple directory with text and code files. You don’t need special editors to create them.
They must follow a very strict hierarchy and file structure.
The folder name is the plugin name : there should be no spaces, no non-ASCII characters in the directory / plugin name
Subdirectories :
config
contains the XML description of the plugin (config.xml), and the localization (i18n) of the plugin. There should be no code in this directory (it would not be accessible via a we browser anyway)
page
contains the JSP pages of the plugin. This is often the case when the plugin is used to modify an existing back-office of front-office behaviour and by extanding it.
res
contains the CSS, images and javascripts used by the plugin.
lib
contains JARs library files that contains triggers, third party libraries or you own code. It is a good practice to also include the source code when possible in this directory. This directory is filtered and not accessible by a end user
...
.
...
Config.xml plugin description
...
The config.xml contains the information needed by the Wedia engine to start the plugin, and present basic information.
It also contains informations needed to build the configuration page.
| Code Block |
|---|
<?xml version="1.0" encoding="UTF-8"?>
<root>
<info>
<version>The version of the plugin</version>
<authors>emails of the plugin authors, comma separated</authors>
<site>if the plugin refer to a specific installation, list it here</site>
<tags>a list of tags used to describe the plugin</tags>
<shortdescription>A short description that will be used in the plugin interface</shortdescription>
<description>A longer description that will be used in the plugin interface<description/>
<example>This section may contain some code example for its use</example>
<faq>A FAQ Url</faq>
<installation>Installation instructions</installation>
<requires>Version of the engine that is required for this plugin</requires>
<services>
This list the services that are offered by the plugin :
# this is the pre 11.5.0 way of declaring services
<PluginLifeCycleBusinessService>method included in the lib JARs</PluginLifeCycleBusinessService>
<ObjectTriggerBusinessService>method included in the lib JARs</ObjectTriggerBusinessService>
<WorkflowTriggerBusinessService>method included in the lib JARs</WorkflowTriggerBusinessService>
# this is the current way of declaring services
<service provides="interface name">implementation name</service>
<service provides = "com.noheto.extensions.interfaces.services.IObjectTriggerBusinessService">method.name</service>
<service provides = "com.noheto.extensions.interfaces.services.IWorkflowTriggerBusinessService">method.name</service>
<service provides = "com.noheto.extensions.interfaces.services.IPluginLifeCycleBusinessService">method.name</service>
<service provides = "com.noheto.extensions.interfaces.services.ISurferService">method.name</service>
</services>
<security>
This list the path of pages that should be restricted to specific roles
<paths>
<path startsWith="/page/admin" roles="Administrators,Developer"/>
</paths>
</security>
</info>
<parameters>
<parameter name="the name of the parameter : this will be a variable, so only ASCII and no spaces" type="text,string,integer or boolean" mandatory="false or true" default="default value" description="A legible description for the parameter"/>
<parameter name="mynumber" type="int" mandatory="0" default="1" description="A value"></parameter>
<parameter name="mystring" type="string" mandatory="0" default="" description="a string"></parameter>
<parameter name="mytext" type="text" mandatory="0" default="" description="A big chuk of lorem ipsum"></parameter>
<parameter name="mybool" type="boolean" mandatory="0" default="true" description="lorem ipsum"></parameter>
<parameter name="email" type="mail" mandatory="1" default="" description="hello@test.com"></parameter>
<parameter name="pass" type="password" mandatory="1" default="" description="Your password"></parameter>
</parameters>
<urls>
If you need to create a clickable link to a specific page of the plugin
or to a embedded or external doc, you ca declare paths that will appear
in a special tab of the admin plugin interface
<paths>
<path bundleKey="url.index" url="/page/index.jspz"/>
<path bundleKey="url.doc" url="/page/doc.jspz"/>
</paths>
</urls>
</root> |
| Anchor | ||||
|---|---|---|---|---|
|
...
Localizing the Info descriptions
The "Info" section gives general information about the plugin and is likely to be localized in a multilingual environment
If you need to localize in multiple languages the information description, you can create new keys in a "plugin_(locale).properties" file in the /config directory of your plugin.
Keys for a specific information should follow this pattern : info.tag_to_be_translated
For example : for an english (en) translation of short description (shortdescription) :
create the <plugin>/config/plugin_en.properties
populate it with info.shortdescription = "This is my short description"
...
Localizing the Parameters descriptions
...
If you need to localize in multiple languages the parameter description, you can create new keys in a "plugin_(locale).properties" file in the /config directory of your plugin.
Keys for a specific parameter name should follow this pattern : parameter_<name>_description
For example : for an english (en) translation of mystring parameter :
create the <plugin>/config/plugin_en.properties
populate it with parameter_mystring_description = "This is my parameter description"