shahriarA dreamer, an inventor, a big time procrastinator…

We all have our ways of writing comments in our code. Some prefer huge blocks of text at the beginning of a source file. Some prefer a paragraph before every chunk of code. Sometime we sprinkles a few one-liners here and there to explain a cryptic regular expression or two. But no matter how we write comments, they always get in our way of coding. That’s why we end up spending very little time documenting. It makes your code longer. Adding new code in between always messes up the comments and then you have to spend some more time realigning comments. Look at the following screenshot and see if any bright ideas come to mind.

Dual-pane source/comment view

I died as mineral and became a plant,

I died as plant and rose to animal.

I died as animal and I was human.

Why should I fear?  When was I less by dying?

Yet once more I shall die human,

To soar with angels blessed above.

And when I sacrifice my angel soul

I shall become what no mind ever conceived.

Nowadays as more of our websites are turning into web “applications” we are being challenged to find newer ways to express complicated UI interactions. Back in the old days we used to think of a site in terms of pages. Each page would correspond to a real file on the server. The navigation area would have links to all these static pages and this is how sites were organized. The introduction of dynamically generated pages didn’t change this model too much. We could still say we are on a certain page of a website and associate that location with a URL. But now-a-days all that has changed. Take any vanilla web application, for example Gmail. What page are you on when you are viewing your inbox, or one of your many tagged folders. The URL doesn’t change. All that changes is the internal state in the Javascript code. Before the web app era the code for managing states could have been segregated into multiple server side scripts. But now all of the state and transition logic is mashed up in one source file.

In this article we are going to look at a mechanism of managing states in an webapp using the Flex framework. Using this as a foundation we will invent our own syntactic sugar to sweeten the deal. First let’s look at MXML code snippet:

The code snippet defines two possible states: 1) stateUno and 2) stateDos. Inside the state tags, some UI update logic is defined declaratively. Moving to stateUno adds a new label to a component called mainBox and sets the label’s text to “State Eins” and font size to 18. Something similar also happens inside stateDos. Let’s see how one would invoke the logic define inside on these states.

The interesting bit of code is the last line. All the code before that is to read the states declared in the markup and store them in an array. The attribute dataProvider=”{possibleStates}” is what lets the button know where to find the list of states. The attribute itemClick=”{currentState = String(event.item);}” causes the UI to move to a specific state. At this point, the Flex runtime does all the hard-work of looking up the state in the array and applying the programmatic logic defined in the first code-snippet.

Now, I’m not a big fan of defining UI update logic to be defined in markup. That’s what scripting languages are for. But I do like the idea of declaratively defining styles and associating them to application states. We’ll now look at the closest analogy to implementing this idea using nothing but CSS pseudo-classes. Let’s look at this piece of code:

This is a typical piece of code for styling hyperlinks. The code causes the hyperlink to appear blue when the mouse is over it, and red if it has been visited. In CSS terminology :hover and :visited are called pseudo-classes. But if you think about it, they are just different states the hyperlink component can be in. Because hyperlinks are components that are baked directly into the browser, the state is updated automatically, and the correct styling for that state is applied from the stylesheet. Sadly browsers currently don’t recognize user-defined pseudo-classes and consequently there’s no way to programmatically set the state of a UI component. But just for a moment, imagine they were.

Add this point, let’s invent some custom HTML and CSS syntax to explore this idea of defining states in stylesheets. Let’s imagine a simple component that shows the strength of a password using a color-coded label.

To interactively update the color of the strength indicator, we would end up writing some jquery to update the class name after determining the complexity of the password. But what if we could write something like this instead:

This looks like a more readable code to me. Here I am making an assumption that states are applied at a widget level. But they don’t have to be. I could have a single call to update the state of an entire app. This would update the state-based styling for all the widgets in the app. Not only would this technique add more semantics to existing CSS code, but it would reduce a lot of the javascript code needed update styles every time there is a need to visually notify the user of a new state.

You can build stadiums that cool themselves, you can attempt to recreate Venice… But you can never fool the sandstorms..

They will keep coming back to remind you of your bedouin past…