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
content
on the website. However, because we were migrating from some old Perl
and
PHP apps, some of those didn’t get converted into Radiant extensions.
For
example, the class schedules are a Perl CGI script, and the Library
Online
Database listings are a PHP app. In order to serve these needs, we
defined
“contexts” (in Litespeed; for Apache it would be a Location directive)
that
redirect to or serve separate applications (some are proxied). Thus,
for
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
extensions to
the Radiant application. It is possible, and with Rails quite easy, to
skin
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
the
URL namespace, then you don’t have to worry about writing code
specifically
to integrate.
On the other hand, if the data your application serves needs to appear
on
multiple pages (for example, our contact information that comes from
LDAP),
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
serve
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
app.
The key, I believe, is to do what’s practical with the minimum of
trouble.
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
moved
on.
Cheers,
Sean C.