Chances are, you'll want to do module development on your own machine. It's only logical, right? This document should make that process a little easier.
Pieces You'll Need
- A Web server
- Module skeleton
- A local proxy
- JavaScript SDK (if you're going to do Ajax modules)
- A local server-side module processor (if you're going to build server-side modules)
- A cautious approach to security
Setting Up A Web Server
If you're going to use our local proxy or server-side module processor, you'll need Apache and PHP5 (or another Web server running PHP5 if you're into that sort of thing). We're not able to provide support for setting up your own Web server, but if you want to, this is probably the way to go. This tutorial over at webmasterstop is a good one for getting Apache and PHP5 up and running on a Windows machine. For OS X folks, you've already got a fine Apache install working for you disguised as web sharing. All you need is the PHP5 Apache module package from Marc Liyanage.
Using A Local Proxy
For PHP, we've found no better way to fetch URLs than the PHP class called Snoopy. So, our proxy for module development requires it. Download it and put in your the root directory of your Web server. Then, download our local proxy (remove the .txt extension) to the same directory, and you've just installed a local proxy!
To try it out, try http://localhost/proxy.php?url=http://aim.com (you may need to change that URL to match where you have things installed). That should give you some version of the AIM home page, and it probably looks really funky.
JavaScript SDK
You'll probably want to have a local copy of the SDK, especially if you're going to use our local proxy to grab Ajax-y things. So, first off, go download it. Unpack it ,and throw it into your web root, or whatever directory under your web root that you're going to use for development.
If you're going to do Ajax stuff with the SDK, you'll need to make the following change to conf.js (line 2). It currently should say:
var modulePROXY="/.resource/Proxy?url=";Change it to:
var modulePROXY="/proxy.php?url=";(or whatever the URL is to your local proxy).
Using Our Server-Side Module Processor
While playing around with how to do server-side modules, we came up with a prototype server-side module parser in PHP. We're giving it to you here free of charge, guarantee, or warranty (use it at your own risk) because we're swell. So, if you're interested in doing server-side module development, go get it and install it in the same directory where you've put the proxy and Snoopy. Also grab news_example.html and headlines.txt and put them in the same directory so you can test this out before you write your first module. The first time you go to parser.php in your Web browser, you should see a module that has five slightly offensive headlines in it. If you don't, you did something wrong... or we did.
To try out your server-side modules, the URLs in pub:src and pub:style must be absolute (containing http://... plus the full path to the resource), and you can't have any style attributes in the same element as pub:style (because of some funky namespace stuff in PHP5's DOM implementation). To test your module, go to http://localhost/parser.php?page=yourpage.html where "yourpage.html" is a file saved in the same directory as parser.php (again, you may need to change the URL if you installed in a directory other than your web root).
A Cautious Approach to Security
Both the local proxy and parser are not production quality, and therefore are pretty insecure. You should never install them in a production, world-accessible Web server, and should probably remove them if you're not going to use them. These are prototype, pre-alpha pieces of software and could be considered more dangerous than helpful (especially if used in the wrong way). We provide them here just to make your module development a bit easier.