Cross Domain Support, if both site a.com and site b.com support my implementation, they will not delete or modify each other domain information

optimized boot strap for frames and iframes, the storage parsing and reassignment is performed once and not every time which means zero delay when an iframe is injected or more frames uses the same implementation

Finally, few bug fixes and this version is both W3C Draft compatible and cross browser.

Known Supported Browsers

Chrome 1 and 2, version 3 or 4 should have native support for Web Storage

Internet Explorer 5, 6, and 7, 8 has native support for Web Storage

Opera 7, 8, 9, and 10 beta, hopefully 10 final will have native support

Safari 3, version 4 has native support for Web Storage

Firefox whatever version, since it supports Web Storage since version 1.5

Google Android and iPhone, but latest WebKit releases should support Web Storage

This is a mixed list of almost all A-Grade browsers but about Android and iPhone, the total amount of available RAM could be 2 Mb.It is not suggested to store in any case massive amount of information but so far I have putted every kind of library avoiding server requests for each tab session and without problems.The sessionStorage aim is, in any case, to remember an arbitrary amount of data for each session and for each tab, surpassing cookies limits without number of keys or amount of data limits.

This project will be part of vice-versa library in order to make vice-versa the cross browser "lingua franca" W3 framework able to bring standards where these are not present yet.

1.4 Special Guests

I would like to say a big thanks to Jonathan Cook (J5 in WebReflection comments) for his suggestions, patience, and ideas exchange ;)

Monday, August 17, 2009

If You do not know what is the Konami Code you are too young, or not geek at all.In both cases, it does not matter, nobody is perfect, but what we should know is that some truly affectionate developer though to put this code to enable secret user powers, even if the the software is, as example, extremely recent.

So why not? Why can't we all have our secret mode in the most popular platform as the World Wide Web is?

Sunday, August 16, 2009

My last sessionStorage is basically ready to implement storage events but apparently I cannot implement them right now. Why not? Doing some test I just discovered a lot of inconsistency for each browser which supports Web Storage in core, so here I am with a little report and some suggestion.

The Correct Way To Set or Get Items

Everysingleexample I've read so far about Web Storage is not respecting standards defined by the official draft, even if related browsers respect the official API.

// bad sessionStorage usage exampleif(sessionStorage.myKey !== null){ // not implementable with old browsers // it could inherit from a modified Storage prototype // it could be a false positive with native API} else { sessionStorage.myKey = "myValue"; // requires getter/setter, improbable with other browsers // it could overwrite native properties or methods // sessionStorage.key = "value"; will *break* the object};

The problem here is that if we follow W3 we are "safe enough" while if we use the quirks way to access or set properties, we will never know how the browser will react. An error because we tried to overwrite a native property or method? A silent operation that will break the object? A silent operation that will not break anything but that will make the logic inconsistent?

Which Browser Does Not Break Itself

Apparently, the only browser that implements internally a private dictionary, rather then set or get values from the sessionStorage instance itself, is Firefox. Both Internet Explorer 8 and Safari are able to make a sessionStorage, or a localStorage, useless. My implementation? It does not break the object, Firefox behavior!

sessionStorage.setItem("setItem", "break it!");sessionStorage.setItem;// the string "break it" rather than the API method// setItem is not usable anymore in the whole page

As we know that we should never extend Object.prototype, how come every browser and every related example here suggests bad practices and/or allows us to easily break these objects?Via official W3 API and bug fixes, we would like to be absolutely sure that setItem will never break the object itself and that getItem will always be the native API method.

Empty Key Support

OK, this is not a massive issue cause an empty string as key is something too silly to use.On the other hand, since a Web Storage should support any kind of key as is for a generic object, where object[""] = 123 is normally saved, I wonder why Firefox browser does not save anything and it does not fire any kind of error as well.

I would like to have a unified behavior here as well ... don't you agree?

Storage Events - Nobody Compliant

This is the most interesting part of my analysis about Web Storage implementations, nothing is working as expected.Firefox and Safari do not fire events at all, or at least I have not been able to do it.Storage Events should be fired in the document, for gosh knows which reason (I rather prefer listeners in storages or directly in the top context, since everything is about the top window context).Apparently storage events are two: onstorage, and onstoragecommit.Both events are not described yet in the official draft so these are how Internet Explorer implemented them, and in an inefficient way.

Funny enough, a web storage event in IE fires with clientX and clientY properties, extremely useful for a storage operation, isn't it? It does not matter, the problem is that there are no extra arguments and every expected property is not there.At least, we have an event that fires in every storageSession present in the page, nested pages (i/frames) so it is usable as listener.Accordingly, first usage of sessionStorage events will require developers skills to be implemented:

// unless we do not check each property // in the storage, there is no way to understand // what has been changed here

// we check if the sessionStorage is trying // to tell us that something has been changed // get("modified") will be null until it is set // if we have more than a context (frames) // we would like to perform the task just once // this is why modified variable is used if(modified !== sessionStorage.get("modified")){

// we can decide which action we should perform here // and we should prevent next event execution switch(modified = sessionStorage.get("modified")){ case "change userName": // do some query or something else // with the userName sessionStorage.get("userName"); /// etc etc .. break;

case "otherAction": // ... } }};

// define somethingsessionStorage.setItem("userName", "Andrea Giammarchi");// nothing is performed in the event

// now we want to perform somethingsessionStorage.setItem("action", "change userName");

})());

Above example is just simple and not perfect but it is a hint about curent event management at least in Internet Explorer.As Douglas Crockford did when He discovered JSON, we could enrich our event notifier protocol using JSON rather than plain strings, it is up to us.

Should I Fix Other Browsers ?

At this point I could decide to fix Firefox and Safari plus add events in my implementation for every other browser.The problem here is that standards are not definitive and IE is alread messing up these standards.Being sessionStorage and localStorage completely different objects, a type property in the event with value "storage" does not help at all to understand which one out of two has been changed ... or maybe, since onstoragecommit has never been fired in my tests, this event will be associated exclusively to the localStorage only ... who knows!If I implement this behavior I gonna slow down events assignment due to addEventListener or attachEvent wrappers.The alternative is to call, if present, the onstorage event for each document part of the same session. Still, it should be in core and a fake event object could just cause more problems so I am kinda stuck with storage events but I am pretty much happy about the rest cause everything seems to work as expected.

As Summary

There is one thing I am concerned about: is this what HTML5 will mean for us? Do we need to test every single new interface to fix or change their behaviors? Isn't HTML5 purpose to make things more standard and less problematic?As we can see there are already "gotchas" everywhere and for a single, simple, misinterpreted interface as Storage is.Examples are different and confused, specially the Safari one uses both setItem, getItem, and direct properties access too.Behaviors are not the same and there is something missing or different for each browser (I'll test Google Chrome ASAP as well).Well, HTML5 is good, but we all should try to do not mess it up with quick but not-standard or problematic implementations.

Friday, August 14, 2009

While I was creating a stand alone implementation of the LSSP described in my last HTML5 sessionStorage project, I did some test and bench as every Agile developer should do.

Well, what I have discovered, is that apparently Internet Explorer could perform some common task better than any other browser, at least in my good old Intel Centrino 1.6 Ghz.

I have created a benchmark page able to freeze my Firefox 3.5.2, to ask me if I would like to continue an Array.join execution with an average score that points out my Internet Explorer 8 wins with a score under 300 milliseconds against Chrome, Firefox and Safari.

As summary, is my Centrino dead or there's something we all did not consider about JScript engine?

Thursday, August 06, 2009

One of my favorite Windows Desktop Application Project, PAMPA-J, is not dead ... it is simply "waiting events", if any.

What Is Going On With Aptana Jaxer

I have no idea! The most exciting news about PAMPA was the J at the end: Jaxer.Apparently this project is in stand-by: while it has been always present in the Aptana Home Page, it disappeared even from Aptana Cloud Page - apparently, they are not hosting Jaxer anymore ... cool! What should I do then? I know is there a way to go in the Jaxer page, but at the same time precedent signs let me think something truly bad happened to this project. Does anybody have any idea about it?

What Is Going On To PECL For Windows

The pecl4win build box is temporarily out of service. We're preparing a new build system.

I know PHP 5.3 put in core a lot of PECL libraries such mbstring, iconv, APC, APD, etc etc ... but I wonder when we will be able to add our favorite custom libraries without compiling them for a single machine. I am particularly waiting for runkit and operator, but apparently these two extensions are not going anywhere and PHP 5.3 support is not ready yet. Does anybody have an idea about PECL?

What Is Going On With PHP 5.3

Apparently, the PHP team has to celebrate a lot for their 5.3 release. It is the first time in years they come out with a release that is not overpatched after few days.As soon as they announced PHP 5.3 I installed it in PAMPA-J without problems (change the php.32 folder, overwrite a couple of apache dedicated files, that's it, some minor simple change in the php.ini and nothing else).At the same time I was sure in few days they would have patched 5.3 with a 5.3.0.1 but it did not happen. After holidays, and too many days from the event, I am waiting for the 5.3.1 already available as dev distribution.

What Is Going On With MySQL

Good question! After I released PAMPA-J, MySQL has been acquired by Oracle. Right now I have no idea how is the MySQL development status, neither which version should I put in the next PAMPA-J.

What Is Going On With Apache

Nothing so far, but at least I realized for Apache 2, 2.X in PAMPA-J, the suggested PHP version is the one compiled in VS2005 and not 2008 (suggested for IIS). Next PAMPA-J will contain the right version of PHP to guarantee better stability.

What Is Going On With Me

I have to admit I am a bit bored by PHP Programming Language. The language itself is great and fun, but its intrinsic limitations plus missed PECL plus people still writing $email to retrieve a posted mail field, plus articles that are never up to date and suggest PHP4 code, plus people still complaining about short tag while PHP problems are, trust me, much more than that ... plus me working over C# and .Net since months, plus me interested in django, plus ... well, you got the point, PHP is behind as programming language, even behind JavaScript, surely behind Python, Ruby, Java, C#, and others.I am not talking about "what you can do with PHP look there is Wikipedia and Facebook", I am talking about language malleability, features, etc etc ... just the fact somehow operator overload is not supported slashed me on the floor every time I think about the next revolutionary library able to make everything type hintable. No way ... they are pushing so much to badly clone Java language without considering missed overload, mess with public and static, slow OOP against procedural, double API for everything (OOP/procedural) ... guys, what the hell is becoming PHP language? The Emperor of hybrids languages, so hybrids that one day it will be slower than every ther due to SPL massive usage from everybody trying to surpass PHP limits. Ok, it's malleable cause SPL let us do that stuff, but how much slower is an OO application entirely based on getter and setter for a language that was truly fast when used procedurally? Make a decision, take a direction ... frameworks are castrated right now and there is something wrong we should get rid of ASAP. That's me about PHP.

Speed will be the same with every browser, IE will do some extra check only if passed argument is not a function.The "native" case could be a performance greedy check and we do not like eval in any case.The "isFunction" name is not appropriate, cause a function is not a Host Object, as is effectively alert, as example, in Internet Explorer.isCallable simply gets the best from old proposal, threading edge cases in a specific way for the edge browser, Internet Explorer.Enjoy!

Monday, August 03, 2009

One truly common task in JavaScript is to determinate if a specific "reference" is a Function, as we know them, or not. For those guys whose think typeof, instanceof, or Object.prototype.toString are enough, here I am with the proof things are NOT that simple, and these things are really important, business speaking, since these checks are in the core of whatever library we create or use for our Web 2.0 Application, Enterprise or not.

Different Behavior Problem: Internet Explorer

As historical black sheep in the browser panorama for its non standard JavaScript implementation, even for a simple task like the right manifestation of a property or function in core level, Internet Explorer, whatever version, will return false in every case described below:

// alert is a function, that is why I use// this function to demonstrate// that for IE alert is not a function// sounds fun?

alert(typeof alert); // object

alert(alert instanceof Function); // false

alert(Object.prototype.toString.call(alert));// [object Object]

Function.prototype.toString.call(alert);// Error: Function expected

NO WAY, Internet Explorer think that every native function is a property with a getter that if invoked, even internally via native prototypes, returns an invokable object rather than its "call".An invokable object is reproducible in this fake way, and it is basically a function which is an Object ... OMG, did I say function?

Do Not Give Up!

Since there is apparently no way to define if a native function is a function, jQuery library, as example, simplified its own isFunction public static callback.The reason is ... reasonable:

.isFunction is simpler now, it no longer handles some strange edge cases (in favor of simplicity and performance)

Good stuff, simplicity and performances, plus edge case removal, is probably the right direction. But, what if we would simply like to understand if a function is actually a function?

isIENativeFunction Proposal

As I wrote in the jQuery developer mailing list, this little snippet will most likely solve every problem:

jQuery.isIENativeFunction = function(f){ // WebReflection Proposal

return !!f && // cause we want return true or false

typeof f.toString === "undefined" && // cause native functions do not // contain a toString callback // as is for every user defined // function or object, even if deleted // so next step is a "safe" destructuration // assumption

/^\s*\bfunction\b/.test(f) // cause we are looking for a function // and IE shows them with function // as first word. Eventually // there could be a space // (never happened, it does not hurt anyway) ;};

we can have under control every kind of check, when and if necessary, thanks to a simple double check that 90% of cases will stop at first call for every browser (I assume we check functions most of the time) and only for IE it will call the second check when the function is a native one. If that will not be a function, well, IE and every other browser will simply return false.

// seriously, I want to know if that// was a function ...

if($.isFunction(f) || $.isIENativeFunction(f)) f();

Not Only jQuery

What if we would like to have a portable isFunction clever enough to understand every situation only when we need it?

// test if a function is native // simply trying to evaluate its // original Function.prototype.toString call function test(f, n){ // it should be a function in any case // before we try to pass it to // Function.prototype.toString if(n = isFunction(f, false)){ try{ // no execution // just an error if it is native // every browser manifest native // functions with some weird char // that cannot be evaluated [native] this.eval("(" + F.call(f) + ")");

In few words, every browser but IE will tell us if a function is a function, as is right now with the simplified version of jQuery 1.3 and many other libraries.On the other hand, we can understand if a function is a native one with every browser.This operation will cost more and for this reason a true, as second optional argument, is necessary to force other checks.isFunction(f) || isFunction(f, true) should be always true in every browser if f is a function, and it will be evaluated slowly twice only by IE cause other browsers will not pass the internal isFunction check if f is not a function.

One callback to rull "function investigation cases" all? Dunno what you think, but I like it :D

Why A WorkerLocation

I've instantly started to interact with Cartagen guys, via Ajaxian, as I think that is one of the most interesting canvas related project I've ever seen so far (I like Bespin idea but I do like more Notepad++ :P )Since after a first and quick read about the project I proposed Web Workers as possible solution for stressful computations, Jeffrey Warren put on the table the fact that Web Workers are not cross browser yet (Internet Explorer 8 anybody?).Being a developer whose aim is to solve problems, I started to analyze Web Workers specs in order to re-create a cross browser implementation able to let us develop following new standards and bringing them somehow in those browsers where these standards are not standard yet and gosh knows where they will be (Internet Explorer 9 anybody?). Something Google did before with ex-canvas project: when a browser is behind it cannot block everybody else (it should NOT, at least).I am not sure how possible/good will be my implementation and it will take time, probably too much to propose it to Cartagen guys but right now I have created a cross browser WorkerLocation which is simple and fast enough to be used in any other project.

After several tests, I can say that results are always exactly the same of a native location object.

What's WorkerLocation For

Well, runtime script inclusion a la JSONP or just to load dynamically our library is a common practice and moreover, an URL decomposition attributes could be always useful in different situations, with script sources itself, to load other files, to check a link, etc etc ... enjoy ;)