Tom Mollerus' Weblog

Have you ever entered content into a wiki using the Wikitext markup language? Wikitext was created with the goal of being simpler to write than HTML. That may be so, but that still doesn't make it easy, especially the first time you try to use it, and especially if you're a non-technical user. So what should you do if you want your user base, all of whom are decidedly not technical, to actually start using the wiki you created for them instead of ignoring it because they don't want to bother learning a markup language themselves?

That's the question we had to ask ourselves at work as we configured a wiki for our sales team, who, while a nice bunch of folks, isn't going to learn the wikitext markup specification just to make us in the operations team feel happy. Luckily, we found a better way to let sales enter content content into our wiki.

I was tasked with providing a wiki application for the use of the sales team here at Ping Identity. For the sake of a mature solution, we chose to use MediaWiki, which is the open-source PHP application that runs Wikipedia.

MediaWiki is built to support the same editing system that Wikipedia is founded upon: namely, to let anyone create or edit content, and do so via a self-created account or anonymously (with the IP tracked). Now Ping Identity, as a single sign-on and identity management software, is all about easy identity management. Besides the fact that most of our users from sales would balk at having to create yet another user account, I would be breaking faith with the company if I didn't allow automatic provisioning (ie, the automatic creation of new accounts if they've been authorized by our AD server). So, after getting MediaWiki installed, I went off to search the blogosphere for single sign-on solutions to make our Apache web server authenticate against our Active Directory service, then have people automatically recognized and provisioned as necessary by our wiki.

Boston's own Brian Rinaldi has just authored an article on SitePoint, ColdFusion 8: Believe The Hype. In it, he tells web developers about why they should consider using ColdFusion 8, with details on increased speed, stability, AJAX integration, server monitoring, debugging, and other items. All in all, the article is a great read. Kudos to Brian for working to publicize the great strides that Adobe has made in an already-fantastic development platform.

One topic that I'd like to see more of in ColdFusion articles, though, is why a developer should switch to ColdFusion from another environment, or what the specific advantages of CF are over other languages. Until this kind of thing is addressed, I don't think that people who have already invested their time in PHP or Ruby on Rails will bother to even consider CF, not to mention bother to read CF articles. Brian quotes a ColdFusion developer at The Economist who recently upgraded to ColdFusion 8, who says, "...the whole thing is ridiculously stable." That's absolutely true, but when we have a former PHP/RoR developer saying that instead of a CF developer saying it, then we'll have reason to really shout about it!

(Sheepish) Yes, I know, I should probably just volunteer to write an article myself... but I want to encourage others to do it as well.

When you click on the "Member login" link on the Text Link Ads site or respond to a comment through the admin section of a Movable Type installation, you'll be presented with a new form in a slightly different manner than you're probably used to: instead of being sent to a new page, or seeing a popup window, the current page darkens, or "greys out", and a form appears immediately overlying it. It's a really neat way to keep the user in the current page context, and it neatly gets around the growing tendency for users to suppress popup windows.

They both do it with Lightbox Gone Wild, which is an adaptation of Lokesh Dhakar's Lightbox project. It's a very easy technique to pull off... link to three script files and one stylesheet in your main page; create a second page containing the code for your form; and then put a link to the second page in the main page with a class of "lbOn". Complete instructions can be found on the Lightbox Gone Wild page.

I know that cfwindow offers some of the same functionality, but it seems to me that cfwindow can't achieve the same level of flexibility as Lightbox.js can. For instance, I think cfwindow is somewhat more limited in how much of it you can style, and is also limited in whether forms in the dialog area can target the whole page.

I've written about how you can send data to ColdFusion from another task on your server, such as passing an email from your mail system to CF through a shell script. But what if the shell script doesn't work, or what if you're on Windows and don't have access to scripting at all? Well, you can also use PHP to pass the data. Here's how.

• Distributing emails to a dynamic, user-defined list of recipients;
• Handling unsubscribe requests and subsequent feedback;
• Auto-responding to support requests to let the user know their email has been received;
• Parsing email campaign bouncebacks and marking hard bounces as bad email addresses, and;
• Adding senders to a newsletter recipient list.

Fortunately, PHP fits nicely into the role of a scripting language which can talk to your application databases (to get user data), generate emails, and be called as a command-line interface by your mail program. That's the most important part-- many web languages support reading and sending emails and talking to your database, but few are accessible both as application servers and as command-line programs. I'll explain how to write such a script next.