Thanks for the suggestion. I'll see about putting some together. Wasn't really sure about including examples as to whether it would be helpful or not...
In writing the article I found I had a tough time putting this one in to words. If you've got experience in writing server-side code, this is already pretty ubiquitous thanks to the "fat model" paradigm. Basically, a given object should manage it's own state and everything else should ask it about it's state.
Consider the direction type selector in Google Maps: http://i.imgur.com/5zQcp.png. I would create an object that manages all those buttons. The object would keep track of whichever button is selected and would probably emit an event that said "user changed selection." Then the controls that, say, sent a request to the server for a new set of directions would query the object for the current state.
Couple of advantages here.
1. It's UI-agnostic. That is, the other controls on the page don't have to care how it's actually rendered at all.
2. It's encapsulated. There's a single way to get the selected direction type.
3. It's much more test friendly. You've essentially abstracted away the DOM for that control.
The hard bit about doing this in JavaScript is it's unenforcable in a team environment. What's stopping the other devs from reaching in to the DOM and querying for the selected button?
Not to be polemic, but I agree that there's something in the current typographic settings that could be improved. I tried to disable the CSS rule from corporate.css::1 on body for font-family (making the font fallback from 'Myriad pro' to the Helvetica family from foundation.css::75) and I think the result is much more readable - although it still has space for improvement in line-height and contrast). HTH
9 comments
[ 2.7 ms ] story [ 33.9 ms ] threadConsider the direction type selector in Google Maps: http://i.imgur.com/5zQcp.png. I would create an object that manages all those buttons. The object would keep track of whichever button is selected and would probably emit an event that said "user changed selection." Then the controls that, say, sent a request to the server for a new set of directions would query the object for the current state.
Couple of advantages here.
1. It's UI-agnostic. That is, the other controls on the page don't have to care how it's actually rendered at all.
2. It's encapsulated. There's a single way to get the selected direction type.
3. It's much more test friendly. You've essentially abstracted away the DOM for that control.
The hard bit about doing this in JavaScript is it's unenforcable in a team environment. What's stopping the other devs from reaching in to the DOM and querying for the selected button?
Hope that helps a bit...