In This Issue...

• Introduction
• Spank Your Corners
• Server-Side Effects of AJAX
• Rethinking Standards Redux
• New Technical Articles
• Techy Forum Threads
• More Techy Blog Entries

Featured Release: Ektron CMS400.NET v6.0

Just Released Version 6.0! Want to post a blog to your Web site? Add message boards & forums? Track visitors and manage your entire membership base? Do you also want to manage content and documents?

Ektron CMS400.NET lets you do everything you want to do on the Web but still do everything you need to do on the Web. Use Ektron CMS400.NET to:

• Manage content & documents on the Web
• Track Web site visitors with site analytics and Web traffic reports.
• Interact with polls, surveys, & HTML forms
• Notify visitors with subscriptions & Web alerts
• Build online communities with blogs, forums, & memberships

Want more? Click here and download a FREE TRIAL now

Introduction

I'm putting together proposals for a couple of conference talks later this year (stay tuned!). Of course, hot subjects like AJAX and JavaScript are on the agenda, but I'm thinking about the server side of things as well.

It's safe to say that the jobs of cutting-edge web developers are in a state of rapid flux right now. Suddenly, everyone wants responsive, interactive interfaces -- not just up-to-date, readable content. Your JavaScript skills can determine your job prospects.

But how are things changing for the server-side code jockeys of the world? If you write (say) PHP all day, do you need to worry about all this AJAX stuff?

Well, setting aside the fact that many web developers are expected to write the client-side code of the sites they build as well as the server-side stuff, rich web applications do affect the way you should approach server-side code. In this issue, I'll explore just a few of the considerations that come to mind.

Spank Your Corners

As mentioned in the Design View #20, SitePoint designer Alex Walker has been plugging away at a new technique for producing rounded corners in browsers that don't support the border-radius CSS property. The technique works on all popular browsers (IE, Firefox, Safari, Opera et al), does not use JavaScript, and requires no added HTML markup (like extra <div>s) -- it's pure CSS. With ideas from almost everyone here at SitePoint HQ, the result is Spanky Corners. Check it out, and read up on how it works!

Server-Side Effects of AJAX

The face of the web is changing, and those changes are more than skin deep. Server-side developers need to adapt to accommodate the rich, AJAX-powered designs that are increasingly in demand. Here are just a few of the things to consider.

Separating out presentation code is more important than ever

As nice as AJAX is, you still need to provide an alternative for users with JavaScript disabled.

Whether you redirect users to a simplified version of your site, or you write your AJAX code so that it will gracefully degrade to hyperlinks and form submissions with JavaScript turned off, you're going to end up processing requests that should do the same thing (like retrieve a database record for display) present the results in one of two entirely different ways.

If you're still embedding your request processing logic in with your HTML code, you won't be able to do this in a manageable way.

You must avoid a whole new set of gotchas

As much as we would like to treat requests from JavaScript code just like any other request from the browser, there are differences. And with those differences comes a whole new set of pitfalls just waiting to swallow up the unsuspecting server-side coder.

Some of those pitfalls, like the fact that the content of AJAX requests is always encoded in UTF-8 (instead of the encoding of the current page, as is the case with forms), are being documented day by day, but no doubt others still lurk in obscurity, waiting to cause problems.

Security requires thought (again)

After many sites learned it the hard way, most competent server-side coders now understand the need to sanitize content submitted from forms. Such content can contain HTML or JavaScript code that will do terrible things when displayed on your site, or it can contain code that will foul up communication with your database, granting access to protected information or destroying valuable data, or it can even contain server-side code that your application could be fooled into executing.

For some reason, however, developers are forgetting these painful lessons when it comes to AJAX development. They are assuming that, because a PHP script was designed to receive input from their own carefully-crafted JavaScript code, it will never receive input from anything else.

Anything your server-side code receives from the browser is potentially a bundle of pure evil. Remember to treat it accordingly.

If you've encountered any other situations where AJAX and other "Web 2.0" type stuff have had an impact on your server-side code, I'd love to hear about them!

Add SMS text alerts to your website!

Clickatell offers developers simple SMS Gateway connectivity via a powerful API. Our API provides you with all the tools you need to incorporate mobile messaging into your web sites and applications in just minutes. Features include:

• Global SMS Delivery to 569 networks
• Advanced messaging feature sets
• Bulk SMS capacity
• Wholesale SMS pricing
• Simple Online Control Panel
• Real time setup and 24/7 accessibility

Signup for a free trial & get 10 test messages

Rethinking Standards Redux

Following my thoughts on W3C standards last issue, a couple of readers wrote in with thoughts of their own.

First, reader Nathan Rutman wrote in with some doubts about my opinion that W3C standards should follow the lead of nonstandard browser features where appropriate, rather than attempting to prescribe features that may not be practical to implement.

"The one question that immediately popped into my mind is, "Isn't that [what got] us into the mess of browser inconsistencies?" IE does things one way, and Gecko and Opera (in the spirit of capitalism and competitive advantage) implement similar features that may work differently or have slightly different methodologies."

Perhaps, but what is keeping browsers from doing that today anyway? Developers are smart enough not to use such features on sites for general consumption. That's why the Geckos and Operas in your scenario would be motivated to propose a W3C standard if they wanted to support IE's nonstandard feature of the week (see step 3 of the process I proposed last issue), rather than just forging ahead with their own nonstandard implementation.

It seems to me that the days are long gone where a single browser can win marketshare by adding nonstandard rendering features that no other browser will support. Such features may gain traction in environments that have standardized on a single browser, or where the browser's rendering engine is used in embedded applications, but developers writing for the Web will wait for cross-browser implementations based on a W3C spec.

At the very least, a new W3C recommendation should require a commitment by someone (anyone!) to implement it.

Secondly, Leigh L. Klotz Jr. from Xerox Corporation took exception to my remark that "there were no browser makers involved in the development of XForms, which probably explains why no browsers support it."

"A number of vendors in the embedded systems browser space are members of the XForms working group. Given that web standards make it easier to write browsers, it's not surprising to me that more niche players are involved."

He also pointed out the Mozilla XForms Project (which I have written about at length in this newsletter before) as an example of a mainstream browser maker currently devoting development time to XForms.

See you next issue, by which time I should be able to announce the conferences where I'll be appearing later this year.

Kevin Yank
techtimes@sitepoint.com
Editor, The SitePoint Tech Times

Help Your Friends Out

People you care about can benefit from the wealth of information on new and maturing technologies available on the Internet. Help them learn how to do it by forwarding them this issue of the SitePoint Tech Times!