paulsobocinski's blog

Whether we like to develop it or not, the registration process is a key element to any website. The marketing, sales, and development teams always seem to be at odds over the issue of agreeing on the perfect registration form.

At what point in the engagement / sales process should a customer be prompted to register? Should the form be split in parts or put all on one page? What questions should be asked? What order should they be asked in? Which ones should be required/optional?

In many cases, an online business's key strategy is to get as much user information as possible, as this is generally considered to add value to a corporation. However (as you can probably attest to personally), customers are loathe to give out any personal details, and may even be prepared to provide bogus information. Not only must companies worry about maximizing customer registrations, they also have to worry about the depth and accuracy of the information gathered.

Lately, I have been focusing a lot on applying separation of concerns to HTML and CSS, and how it fits into the broader topic of web standards. But what about client-side scripting, or web site "behavior"? We need a similar "best practices" methodology applied here, too.

Why "best practices" for JavaScript?

There are many reasons why we need to do this. First of all, in JavaScript, there is more than one way to achieve the same goal. For example, we can use both innerHTML() and DOM manipulation functions to change the content of the HTML page (more on this later). Is one of these ways better than the other? If so, which one, and why?

I admit, I have been talking quite a lot about the Separation of Concerns principle -- in fact, this is the fourth post I've made about the topic (abbreviated SoC from this point on).The fact of the matter is that the issue needs to be addressed to its fullest extent, as the greater concept of web standards gains increasing importance on the web (many supporters of this claim exist; Microsoft is one of them).

In previous posts, I have talked about SoC in a historical context, the limitations of CSS, and the need to overlap the concern of dynamic presentation with JavaScript and CSS. In this post, we first address the concerns of "content" and "layout." We then distinguish between "structural" and "positional" layout, and elaborate on the tremenduous importance of the former as a first step in web design (search engine optimization, anyone?).

In my last post, I talked about the limitations of using pure CSS for the "presentation" component of the web application model. In this post, I talk about the issue of "dynamic presentation," and which language to use for its implementation (JavaScript or CSS).

I have expanded the table previously discussed to help distinguish between "static" and "dynamic" presentation:

All of you might be scratching your heads and thinking: "what was the point of the history lesson of that last post Paul made?" Essentially, I wanted to show how the languages we use to build websites today have evolved towards the "separation of concerns" principle. Nevertheless, we'd likely have a more fool-proof solution if HTML, CSS, and JavaScript were all invented concurrently.

But this has happened over time, with a large number of corporations and organizations influencing things along the way. Netscape, Microsoft, Mozilla, and the W3C have all played major roles in the adoption and standardization of these languages; web standards is the broader long-term goal of the web development community that encompasses the separation of concerns principle discussed here. As web developers, we must make due with the end result, adhering to this principle as best as possible.

Separation of concerns was one of the first programming principles I learnt, and is one that continues to be very important, in my mind. However, following this principle in web application development becomes especially challenging. With standalone application development, there is usually a framework put into place to encourage this principle to be fully applied. Let’s take the GUI component of an application as an example: Sun’s Java has Swing and AWT, while Microsoft’s .NET has Windows Forms.

On the other hand, with web development, the HTML page is effectively the GUI component of the application. The HTML page is what the browser on the client side parses and renders into a visible, interactive web page. And the HTML page is where the separation of concerns principle for web apps falls apart.

A few days ago, I read an interesting article in my local newspaper that I found surprisingly relevant to the sort of stuff we talk about here. I say surprisingly, because I find web development is still a pretty esoteric field; in fact, the majority of my friends don't have the first clue as to what I'm talking about when they read my articles, or even most of my blog posts.

So I was quite taken aback when I saw an article about corporate social networking on the front cover of the business section of my daily paper. I believe that this fact alone is news in itself. It's an indication that the social networking phenomenon is gaining enough momentum to be visible in mainstream media. Furthermore, the article doesn't talk about social networking in general -- it focuses on the corporate aspect of the concept. In other words, it's about people who use social networking more for career development than for recreation.

Two posts ago, I introduced a high-level design approach that would enable you to move most of your server-side application to the client side. In my last post, I discussed the various reasons for doing so. In this post, I talk about the disadvantages of this web architecture concept.

1: Source Code Visibility

As client-side code is not compiled, but interpreted, all of your JavaScript code is accessible to anyone who runs your web app. Clearly, this makes it easy for a competitor to steal your entire implementation and put it on their site.

A few blog posts ago, I talked about how AJAX is shaping the architecture of web applications. Specifically, the combination of the JavaScript DOM, Event Model, and the XML HTTP Request object allow us to implement components that would otherwise reside on the server-side. For example, instead of submitting a form to the server and retrieving an entire page as a response, we can intercept the submit request by using a custom onSubmit Event Handler. The JavaScript control logic then determines what database communication is needed, and passes the request to the server side using the XML HTTP Request object. It then receives the data from the server and processes it appropriately, updating the application state.