Oct 22, 2011 @ 02:30pm
Session and local storage have made the storage of data on a clients machine respectable, gone are the big cookies and window.name, partnered with the ability to define manifest files developers can now exert control over how resources and data are cached to a level that makes Apache and IIS look embarrassing.
However, with every new feature, some things get easier and some things get harder.
Session storage is held only in a particular tab or window, allocated to the domain and lasting as long as that window persists. Opening the same domain in another tab will create a new session. Local storage is also allocated to a domain but persists between sessions, tabs and windows.
Web storage does not cater for different users, domains and windows are all it knows.
There are additional complications if users on your site are able to login, if your web storage includes data individual to the user you need to take care to clear and refresh data whenever the state changes
How to maintain state between web storage and server sessions
It might be a bit old-school, but Cookies are still the way that most back-end systems track user sessions. The simplest thing to do is to store the value of the session cookie in your web storage and to compare those values when the page loads and if the values differ clear the session of user specific data.
sLocalKey = 'StoredIdentity',
sCookieKey = 'CookieKey',
storedIdent = window.localStorage.getItem(sLocalKey);
sCookieValue = readCookie(CookieKey);
if (sCookieValue === storedIdent) {
return true; //same cookie value
}
else {
return sCookieValue; //different value, new session
}
Another case to watch for is a login/logout events, it's unlikely the cookie value will change (the session existed before login) but either you can watch for a query-string value or particular pages like login/logout success.
Mar 11, 2011 @ 01:42pm
I've just about finished my first site of 2011 and as ever learnt some things along the way.
Lesson one: Killing IE6 only makes things slightly easier
The Internet hates Internet Explorer 6. Not supporting it was a weight off my mind but look at your browser list without it and you'd be forgiven for not jumping for joy. I can't remember the last time I didn't have to make something with gradient backgrounds and fades nevermind, the now standard, rounded corners and drop shadows.
So, positives, I get to use descendant selectors and multiple classnames and feel like I'm programming and not throwing vague rules around. Negatives are I still have far too many background images, I've got Raphael to draw SVG and fall-back to VML, and jQuery so I don't have to write three times as much JavaScript to do things.
Update: I forgot to say that you should use the button tag where previously you'd use input type submit, do it, if only so you can put the span inside the button so it looks right when you focus on it!
Lesson two: Do not be afraid of SVG
SVG are in my opinion one of finest parts of the modern day web toolkit. You can keep your CSS transitions (lets face it, they're propriety and there is too much code for them... keyframes though, they're good) and your webGL (all very Flashy, in that it looks like it's not going to interact well with the other page elements).
The code to create the lines and curves of SVG takes a bit of a jump but if you can keep your mind in it's coordinate language (I wish the 0,0 point was bottom left not top left, I was going loopy trying to draw the graph axis) then you'll soon be comfortable. I just wish my maths was better. Although if it was maybe I'd prefer webGL
Lesson three: Use events to communicate between logical parts of your application architecture
I've been a fan of event driven programming for a while but I've struggled to come up with a good example for using it, but I think I finally have one!
The key part of this project was that we were visualizing data, and that that data might change dependent upon a user or server action. By separating the data from the controller or elements that use it we can simplify our connections to the data and compartmentalize it's operations. The events come into play when those data stores are updated, we broadcast that data has been updated using a traditional event, if a controller has registered to listen for that event then it will perform it's action from that point. It's an alternative to registering the handler directly to the data update function, leaving the responsibility on the listener itself rather than the class handling the data updates.
Lesson four: Learn for the next one
I may have exclaimed that the lightbox was the finest I'd ever built, most of the styling and positioning done through CSS etc. But of course it's not that simple, I'd used position fixed so when suddenly we got some long lightbox designs it's not going to expand the page beyond the viewport. Turns out the JavaScript controlled one I did last year worked better in the real world. Lesson learned
Sep 14, 2009 @ 05:23pm
There is lots of noise at the moment around HTML 5, and Canvas is a big part of that. You may expect the Canvas element to be a straight replacement for Flash, but it's lacking that level of abstraction present in Flash.
The name canvas is literal, the element only acts as a painting area, there is no time-line and objects/graphics are rendered onto the canvas and not stored on it. Once painted on they can be painted over but not moved or modified.
When painting to the canvas we use its context object, functions of which fall into two groups: painting operations and painting settings. For example, if you change the opacity value it will not affect the current canvas content, but it will affect any further painting operations.
The context object can maintain a history of painting settings, with states stored in a last-in, first-out list. Calling save() pushes the current context state to the history, calling restore() pops the last state from the list and resets the context to that state.
The Canvas is for creating dynamic images, so for most applications you'd probably be better off with normal HTML, or even SVG.
