The plug-in builder is a developers' tool to generate code stubs for ExSite Plugins. Answer a short questionnaire, and it will generate perl code, a stub help file, and a stub configuration file, and tell you where to install these.
The various questions in the questionnaire are covered in more detail here:
This is a short machine name for the package, used for its file name and Perl package name. It should consist of alphanumeric characters and have no whitespace.
This is a human-friendly name for the package, used for titles, and icon labels. It should be descriptive, but short. The module name will be used, if left blank.
This is a short description of the module and what it does. This is optional, and is used by some tools that query the available modules on the system.
A copyright notice will be added for this author at the top of the plug-in code.
By default, plug-ins will combine the GET and POST data into an
input
hash, and store a reference to this in the plug-in
object's attributes (ie. $this->{input}
). This is
sufficient for most plug-ins to acquire all the user input they
might need to work with. If that is also true for you, you will
not need a specialized input management method. Otherwise, ExSite
will create a stub for you to acquire your own user input.
Plug-ins can support two main output paths; one goes to public web pages, and the other goes to administrator control panels. Select this if your plug-in will be generating content for public web pages.
If your plug-in has special administrator functions that should not be placed on public web pages, then select this optoin.
Some systems support numerous websites concurrently, but want to limit which sites have the use of which plug-ins. If this plug-in should allow itself to be restricted in this way, then select this option. (In that case, a section will NOT have access to this plug-in by default. You must add a license key for this plug-in to that section [using the Security plug-in] before the section and plug-in will talk to each other.)
If you want the plug-in to be available to all sections, do not select this option.
When a plug-in links to itself (for instance to generate another view of the plug-in content), by default the link takes you back to the same page you started from. Sometimes, however, the plug-in requires its own special layout or template to properly handle these requests to itself, in which case you would rather the self-links to go to a special page that is designed to handle the request. (This is called a "service page" in ExSite parlance, because those plug-ins are serviced by specific pages in the system.) If you require this feature, select this option.
This feature is typically needed by plug-ins that receive file uploads which in turn have to be served back to site visitors (eg. image uploads). If a file upload is placed into the database, then serving that file involves a costly database fetch. It is usually far more efficient to publish the file(s) out as static files and serve them like any other normal site files.
Selecting this option creates a code stub for publishing, and a second code stub for unpublishing (removing files that you have published).
Plug-ins can support "deep" indexing of their specialized content, using hooks into the Search subsystem. Use this option if you want to insert special content into the search index.
If your local installation supports scheduled task management, then your plug-in can tie into this feature. Scheduled tasks can run hourly, daily, weekly, or at preset times.
The optional ToDo plug-in reports on things that require the administrator's attention. If your plug-in knows specific things that the administrator ought to do, it can provide links and descriptions of these tasks for the to-do list.
Select this to add the generic ExSite licensing preamble to your code stubs.