Leading Comma or Trailing Comma: that is the question

Saki — Thu, 03 Apr 2008 11:56:41 +0000

I have found another post that others could be interested in, originally posted on May 25, 2007. The original text follows:

As you may have noticed from code fragments I’ve posted on this forum that I’m using leading commas in my code. People keep asking me about reasons why I have decided so and if there are any positive or negative consequences of this so I have decided to write this article where I would explain my whys. What I would like to state at the beginning is that I do now want this thread to become a war of friends and enemies like some Linux vx. Window$, or Intel vs. AMD, discussions. I do not want anybody to change their coding practices because: The truth for you is that what works for you.

What works for me are leading commas. Why?

First, compiler or script interpreter doesn’t care if I’ve written leading or trailing commas. The only who cares is myself and other human beings that will read, understand, modify and debug the code.

So first comes reading and understanding. Lets take the following examples:

var o = {
    id:2,
    useAccessibilityFeatures:true,
    autoLoad:true,
    name:'demo',
    translateHelpTexts:true
};

In this example, if I want to check if I haven’t forgotten a comma or if I don’t have an extra comma there (infamous IE extra comma error) I have to look at the ends of all five lines with various lengths to see if comma is there and, in the case of the last line, to check that comma is not there.

var o = {
     id:2
    ,useAccessibilityFeatures:true
    ,autoLoad:true
    ,name:'demo'
    ,translateHelpTexts:true
};

In this example I just look at the code as a whole if it has the expected appearance (first line w/o comma to the left and then column of commas).

You know, one line will always be different because number of commas is one less than number of properties.

The modifying of the code or putting some leading comments before the properties to temporarily disable them is pretty same in both cases. What makes bigger difference is a handling of errors I may have done in the code by browser. Let’s make an error in the examples:

var o = {
    id: 2,
    useAccessibilityFeatures: true,
    autoLoad: true,
    name: 'demo',
//    translateHelpTexts: true
};

What happens here? Please-help-my-app-works-in-FF-but-not-in-IE help forum query, waiting for some hours for reply and then not believing: How could I be that stupid?

var o = {
//   id:2
    ,useAccessibilityFeatures:true
    ,autoLoad:true
    ,name:'demo'
    ,translateHelpTexts:true
};

And what happens here? Nice fat syntax error in both Firefox and IE with line number. Finding the line in the code and fix it is the matter of seconds and I can continue with some more important things.

I have better things to do as to hunt a stray extra trailing comma in the code for hours. And you?

Changing Viewpoing to Ext

Saki — Wed, 02 Apr 2008 12:38:35 +0000

I have found one of my older posts to Ext Forum when I have been with Ext for a couple of weeks, just after initial shocks of cognition that if I’m going to use this library I need to step out of my old habits and routines and I need to change my mind about web development.

I think that the original text is very useful for newcomers who would travel same or similar route as I had. There is one more note to it:

Ext made a tremendous step forward since I’ve written this article. Now, server not only does not generate an HTML markup for pages but also it is not needed to generate containers for Ext components. We can do very well with empty body: .

The original post dated June 7, 2007:

I’ve been with ExtJS for a couple of weeks coming from PHP/mySQL world and I must admit that I had to totally change my viewpoint of the application design and I had to go through many trial-and-error attempts to achieve that something reasonable appeared on the screen with a behavior I wanted.

I’ve decided to write on this viewpoint shift to help others to move swiftly to the Ext concept from “the standard web design”. Believe me, you will have to change the viewpoint; be prepared that what you knew before is not valid anymore, prepared to forget the long-years-worked schemes, prepared that you will maybe need to throw away your hardly written, debugged nice PHP (or other) classes or functions.

Well, this doesn’t sound too good, does it? Is it worth to? Shouldn’t I stay in my ruts where everything just works?

Answer is simple: It’s up to you. Brave enough? Continue reading then.

What we are used to? First of all user has an URL to click. When he clicks the browser sends a request to the server. Server prepares the complete page with styling, pictures, tags, forms, labels and mainly with more links (URLs) and sends it back to the browser.

User then fills-in some data and when he/she’s done clicks submit. The new request travels to server, server processes the data and returns another full page (success or failure or new form), right?

OK, forget this! Except of the first request and first page returned it doesn’t work like this. (Well, it may but why to move to Ext then?)

How the hell it’s working then?

Good. We make the first request, something comes from the server but I wouldn’t call it a full page at all. It’s a kind of concept of to-be-the-page. Imagine you have a navigation on the left and main display are on the right. Yes, you have to load something there so the page is not empty but if you have more than on tab in the center you don’t need to load anything into inactive tabs. User maybe never clicks “third one” so why to run server script and transmit data of something that is never requested.

Now, user clicks something in the left navigation and we want to display it in the center. The request is sent to the server but it is different in that that it runs in the background without reloading the main page. When data arrives we just fill (with the great help of Ext) the main display area and we’re done.

We could (almost) say that one site equals one page, or better to say one concept or framework, and that we load the content into this framework on demand in the background.

Well and what about data?

The same! If we need to display tabular data we just use grid in the center and load it with data from server. Beware, when I say grid I mean grid created by Ext not some complex html table prepared by server and sent to client. The Ext grid is nice, full of features that the “classic” can only dream of (sorting, column resizing and hiding and many more) and the only thing it needs from the server is data.

The same is true for trees, views and other components.

And what about sending data?

This was my major pain in the transition period. I kept looking for forms, hidden fields, field names and all well known things wondering why I had troubles to find some. Yes, they exist but concept of form full of inputs and hidden fields then submit then new page as the only way to get data to the server is gone.

Let’s take an editable grid as an example. I see grid and I need to change data in it. Classic approach would be: click, new page or a popup with form, submit, new page with result or reload of the grid as minimum. This was what I was looking for. Never thought that it can be that simple as to (double)click the cell I want to change the value of, change it and that’s it. And how data gets to the server? In background. Works almost like spreadsheet.

What job is left for the server?

Not too much. It has to prepare the main page but there is not much dynamics needed in that so PHP processor maybe stays idle here and a static HTML will do. Then it has to react to requests sent from client for either another static data (HTML fragments) or we wake up PHP (or other) processor to do some validation and/or database engine SQL-ing.

It is incredibly simple! Sometimes that simple that it is difficult to digest the simplicity. Should you have troubles with anything in Ext start to think “How to make it simple?” That is the right way.

A philosophical conclusion.

Ext doesn’t only provide an easier way to do things in browsers. It is creating the new application platform. You do not need to ask anymore if this or that application is for Linux, Mac or Windows. It’s for a browser with javascript and it doesn’t matter which operating system is installed on the computer the browser runs in.

Happy coding!

Saki's Blog » viewpoint

Leading Comma or Trailing Comma: that is the question

Changing Viewpoing to Ext