One solution that has not been discussed, and bears mentioning, is the
creative use of the web server.
On www.kckcc.edu, we have several mini-applications that help serve
on the website. However, because we were migrating from some old Perl
PHP apps, some of those didn’t get converted into Radiant extensions.
example, the class schedules are a Perl CGI script, and the Library
Database listings are a PHP app. In order to serve these needs, we
“contexts” (in Litespeed; for Apache it would be a Location directive)
redirect to or serve separate applications (some are proxied). Thus,
the main website we have the “/” context point to Radiant and the
“/cgi-bin/” context proxies to CGI apps that run on the old web server.
So I guess what I’m saying is, not everything has to be in the
the Radiant application. It is possible, and with Rails quite easy, to
your external application to look like the rest of the site (we did this
pretty simply on a couple apps). Just serve it up under another part of
URL namespace, then you don’t have to worry about writing code
On the other hand, if the data your application serves needs to appear
multiple pages (for example, our contact information that comes from
then the application is a good candidate for an extension.
Of course, there’s also a middle ground where it could be part external,
part extension. For example, if you have a heavyweight e-commerce
application, you could connect via AWS or ARes (or even open-uri!) and
up parts of the data in pages with some custom tags. Then, for the cart
management and checkout, you could redirect or proxy to the e-commerce
The key, I believe, is to do what’s practical with the minimum of
Some of those PHP apps I wanted to convert just didn’t make it for our
January 1 deadline, so we found a variety of ways to support them and