The Movable Type and Professional Network Wiki has been moved to wiki.movabletype.org.

PluginBuilder

[Login] Change #15 by gene.vox.com at 2006-11-13 19:19:07.

This is currently in "document development" stage (AKA vapor ATM).

PluginBuilder is to be a simple MT::App that builds a standardized plugin structure. (Eventually it will become quasi-sentient and help you build the functionality of your plugin. Exciting!)

Please check out the Questions and Speculation section below for the most current action. :-)

Usage

With the MT GUI, we construct a proper, authorized MT object that knows where plugin things live:

http://localhost/cgi-bin/mt/plugins/PluginBuilder/plugin-builder.cgi?name=FooBar&foo=bar&etc=1
The command-line is the ''exact same thing'' (but developed first, of course):

perl plugins/PluginBuilder/plugin-builder.pl --name=FooBar --foo=bar --etc

Package Layout

  - FooBar/
     - CHANGES.txt
     - README.txt
     - MANIFEST.txt
     - mt-static/
        - plugins/
           - FooBar/
              - images/
                 - foobar.png
              - js/
                - foobar.js
              - styles
                 - foobar.css
     - plugins/
        - FooBar/
           - foobar.pl
           - lib/
              - FooBar.pm
           - t/
              - foobar.t
           - tmpl/
              - foobar.tmpl

Error Handling

Plugin already exists.
Permissions problems.
System call failure.
Required perl module(s) not present.
Can't instantiate or access MT properly.
No files to include under the new plugin.
Insufficient or invalid parameter data.

Questions, Speculation...

It should present a basic web form with a plugin name and paths to use when building the plugin.
Use this an authorized MT site upload directory as a place to find the plugin files to include.
Use a handy form with an input for the name and textareas for changes and readme files.
Map files to include, by type, to their proper place under the package hierarchy. This hierarchy is based on Brad Choate's RebuildQueue plugin.
Drop the built archive packages (tgz, zip) into this same accessible area.
Include a MANIFEST of all files in the plugin distribution.
This should be able to know about and not choke-on trivial variations in structure like m/changes(?:.txt)/i and readme files.

The Future...

This should enhance the path specification input fields with the upcoming "MT Asset" functionality in finding files to include and inspecting the plugin structure under construction.
Handle setup of database interaction.
Have MT construct basic, generic functionality bits of plugins.
- Build a skeleton of the code, itself:
- Run object updates, initializations, callback registrations, etc.
- Get feedback from teh smrt ppl!!!!!1
How are external (shared) libraries such as those found in CPAN or Feeds.App/Tags.App handled by the PluginBuilder?
- Excellent question! I envision that this functionality would transparently interact with Byrne Reese's PluginManager.
Support use of Perl::Critic, Tidy or other "sanitizers" out there, through generic qxdefault or system() calls) via MT callbacks.
Include a companion plugin that registers special file types and could restructure the GUI for asset listing to accommodate plugin viewing?

[Login] Change #15 by gene.vox.com at 2006-11-13 19:19:07.