For a little while now I’ve been working on a WebGUI plugin for Padre (the Perl Application Development and Refactoring Environment). Progress has been pretty slow, partly due to lack of time but also because often the things I want to do are at the edge of what Padre currently supports (or just that there’s no existing examples of how to do something easily).
I’ve released the code onto CPAN, and the current dev version is available via github, but since it’s all a bit hacky and alpha at the moment I thought it worthwhile doing a little tour of what currently works (on my dev box at least).
Installation
Installation is the same as any other Padre plugin, either install via cpan
cpan install Padre::Plugin::WebGUI
or from git:
git clone git://github.com/pdonelan/Padre-Plugin-WebGUI.git perl Makefile.PL make && make test && make install
Since this is a WebGUI plugin, you need to first install WebGUI, and also WGDev.
Once you’ve done that, you will see the WebGUI plugin listed in the Padre Plugin Manager:
Click the enable button, and you’ll see a WebGUI item appear in the Plugin menu.
Controlling WRE Services
The first thing you can do with the plugin is control your WRE services (mysql, modperl, modproxy and spectre).
Click on: WebGUI > WRE Services > Modperl > Restart and you’ll see a restart status message appear in the Padre output panel.
Currently this is just a simple wrapper around the wreservice.pl script that ships with WebGUI. A nice enhancement would be to turn the menu item into a services dashboard with lights telling you which services are currently running, and buttons to start/stop/restart.
Online Resources
Another item in the menu called Online Resources gives you access to a bunch of handy WebGUI links that open in your browser – including one that takes you straight to a web-based IRC client connected to #webgui.
WebGUI Log
If you click the “Logview” checkbox on the WebGUI menu, a WebGUI Log panel will open. This panel will start monitoring all of your WRE log files (webgui.log, modperl.log, modproxy.log, etc..) and display changes in real-time. WebGUI uses Log4perl as its logging engine, but it uses the sitename as the Log4perl category, which means that you can’t easily e.g. turn on DEBUG output and filter out everything except the module you’re working on (unless you use my Log4perl::Filter::CallerMatch module). Once we add in the ability to easily customise what files are being logged and apply filters to what gets displayed, this will make the above scenario a breeze.
The logview panel uses a long-running Padre task and File::Tail::select to continuous monitor a bunch of files in realtime. The main thread writes commands to a temp file to send commands to the monitoring thread (the most important command being “exit” which tells the thread to break out of its monitoring loop!). Later I plan on adding support for other commands such as “add/remove this file from the list of files you’re watching”, “add/remove filter”, etc.. Since this seems like a generic sort of feature I’m hoping to bundle Padre::Plugin::WebGUI::Logview and Padre::Plugin::WebGUI::Task::Logview as a stand-alone module for other Padre plugin developers to use (and improve).
Asset Tree
And finally, the coolect feature the WebGUI plugin has is the Asset Tree.
If you turn on the Asset Tree from the plugin menu, a new panel appears with a “Connect” button on it. Currently this is hardwired to the default WebGUI dev site at dev.localhost.localdomain but later I plan on adding a Site Manager to allow you to define sites here.
Double-clicking on the Connect button connects to the site, and pulls down the asset tree:
This is the same Asset Tree you see when you log in to your WebGUI site and turn admin mode on. As you can see from the screenshot, right-clicking on a node brings up a context menu, from which you can do asset-specific actions. The plugin already gives you access to all of the WGDev commands from the main plugin menu (with a dialog box asking you what arguments you want to pass to the command), but it becomes a lot more useful once you hook these WGDev commands to the Asset Tree context menu. Then instead of having to remember what url or assetId your asset has, you can just click through the tree to find the node you want, right-click and off you go.
For example, WGDev has a package command that lets you package up node and all of its children into a tarball that can be imported into other sites, used in upgrade scripts, etc.. By integrating this command into the context menu, you can have Padre prompt you you for the folder that you want to save the WebGUI package in (via your native Save File dialog box).
Similarly, WGDev has an edit command that lets you edit an asset (for example a template file) via your favourite editor and then have the changes pushed back into the database after you save and close the file. By integrating this command into Padre, you could leave the file open, and push the changes up every time you hit save(allowing for more convenient continuous editing).
