Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Plugins authors should adhere to the following guidelines when developing plugins.

Name

The plugin name should be concise and convey some meaning as to what the purpose of the plugin is.

If you find it difficult to name because the plugin functions are so varied then you should consider splitting the plugin into several plugins.

Ideally, plugins should perform their own discrete functions specific to a purpose.

Meaningful Description

Place a meaningful description in the plugin description.

The description should explain the following:

Purpose of the plugin

A brief summary of what the plugin does. Even if there is an external link to a documentation page, the plugin description should still offer a summary of purpose.

System Settings

If the plugin defines any System Settings, the plugin description should at the very least alert the reader to this fact. The System Setting descriptions can explain each setting, but the plugin description should mention that there are System Settings so the reader can know to examine and set them.

Custom Fields

If the plugin defines any Custom Fields, the plugin description should at the very least alert the reader to this fact. The Custom Field descriptions can explain each setting, but the plugin description should mention that there are Custom Fields so the reader can know to examine and set them.

Deployment Instructions

If there are deployment steps beyond just importing the plugin, then these should be listed in numbered order.

Author

The Author should identify the organisation or individual who authored the plugin.

Versioning

The plugin version should use a dotted version number, with the last number incrementing with each published change.

For example, if a plugin is first published as version 1.0.0, then this should be incremented to 1.0.1 when next published.

Exception Policy

The Exception Policy should be set to Abort if it performs critical business processes, otherwise the default Exception Policy of Report should be used.

A plugin with an Abort Exception Policy will not allow processes (such as the REST API or Plugin Scheduler) to logon if the plugin is unable to be loaded.

Execution Order

Plugins are compiled and loaded in the order of Execution Order, then plugin Name.

If you add a Plugin Reference (a reference to another plugin) then the Execution Order is automatically set to the Execution Order of the referenced plugin, incremented by one.

Forms

The Forms tab of the plugin is a register of forms that, when loaded will result in the SetupBeforeHandlers and Setup methods of the FormPlugin class being invoked.

You should only add forms to this list which your plugin has an interest in.

Code

FormPlugin

SetupBeforeHandlers

When a form is created via the FormFactory (as all forms in Jiwa are), if the form is registered on the Forms tab of the plugin, then the SetupBeforeHandlers method of the FormPlugin class is invoked after the form is created, but before the form has added any event handlers for the control or business logic.

The SetupBeforeHandlers method can be used to add handlers to control events and business logic before the form itself handles these events.

This is often useful in overriding the built-in behaviour - for example, adding a button click handler here will cause your code to respond to the event before the form does, and you can also short-circuit the event so the form doesn’t receive the event at all afterwards by throwing a JiwaApplication.Exceptions.ClientCancelledException which will silently fail, resulting in your plugin handling the event and the form not handling it with its built-in handler.

The JiwaForm parameter passed to the SetupBeforeHandlers method is the form being loaded - if you have registered multiple forms on the Forms tab on the plugin then the type of the form should be inspected to determine the code to execute.

public void SetupBeforeHandlers(JiwaFinancials.Jiwa.JiwaApplication.IJiwaForm JiwaForm, JiwaFinancials.Jiwa.JiwaApplication.Plugin.Plugin Plugin)
{
  if (JiwaForm is JiwaFinancials.Jiwa.JiwaPurchaseOrdersUI.MainForm)
  {
		// the Purchase Order form
  }
  else
  {
		// some other form
  }		
}

Setup

The Setup method, like the SetupBeforeHandlers method, is only invoked if the form is registered on the Forms tab of the plugin, but the Setup method is invoked after the form has added its event handlers for controls and business logic.

Typically this is where custom controls are defined and added to the form, and where handlers to business logic or form control events are added.

  • No labels