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.
on 2007-01-16 21:34