PDA

View Full Version : [JAVASCRIPT] Javascript Serialize



shachi
01-07-2007, 03:51 PM
1) CODE TITLE: Javascript serializer

2) AUTHOR NAME/NOTES: Shachi Bista

3) DESCRIPTION: Serializes any string like the traditional PHP serialize function

4) URL TO CODE:

or, ATTACHED BELOW (see #3 in guidelines below):

mburt
01-07-2007, 03:57 PM
I'm not quite sure I understand... What exactly does it do?

shachi
01-07-2007, 04:11 PM
You would if you used the php serialize() function. Anyways it converts any plain text like this:



test
array(1,2,"b");

to:


s:4:"test"
a:3{i:0;i:1;i:1;i:2;i:3;i:"b"}


If you still don't get it then I suggest you to download the zip and check the html file. Even PHP sessions are in these formats.

Hope it helps.

Twey
01-07-2007, 04:21 PM
Under SpiderMonkey:
jserialize.js:10: SyntaxError: final is a reserved identifier:
jserialize.js:10: final = "a:"+item.length+":{";
jserialize.js:10: ................^

Changing this, it doesn't produce the same output as PHP serialize(). Compare:
twey@peordh ~/Documents/ddstuff $ js -f jserialize.js -f -
js> var a = [];

js> a.push(a);
1
js> serialize(a);
a:1:{i:0;a:1:{i:0;a:;}}
twey@peordh ~/Documents/ddstuff $ php
<?php
$a = array();
array_push($a, $a);
print serialize($a);
?>
a:1:{i:0;a:0:{}}

shachi
01-07-2007, 04:23 PM
Twey: Haven't tested it in all browsers. I never knew that even final was a reserved word. Too bad. Do you think changing that varname will fix the error?

Twey
01-07-2007, 04:33 PM
It does. However, the difference in output remains.

shachi
01-07-2007, 04:57 PM
It does. However, the difference in output remains.

How come??

Twey
01-07-2007, 04:59 PM
Sorry, I modified my above post, apparently after you read it.

mburt
01-07-2007, 05:01 PM
Umm yeah... Well. I have a question, what does the "final" keyword signify?

shachi
01-07-2007, 05:10 PM
mburt: I just have no idea.

Twey: I've got to fix that too, that goes into my TODO list, Thank you for pointing that out Twey. If I am lucky enough I'll certainly fix it.

There still are a lot of bugs that needs to be fixed. This is just an experimental script I created for AJAX to transfer and convert js arrays so that PHP can interpret them.

Twey
01-07-2007, 05:43 PM
what does the "final" keyword signify?In Java, it signifies a constant. In Javascript, nothing yet (as far as I know), but the ECMAScript standard defines it as being "reserved for future use."

/EDIT: My error, array_push() wasn't doing what I thought it was. The expected output is actually:
a:1:{i:0;a:1:{i:0;N;}}

mburt
01-07-2007, 06:36 PM
but the ECMAScript standard defines it as being "reserved for future use."
So it doesn't initiate the statement right away? I'm really new to the final variable name, so I'm probably wrong.

shachi
01-07-2007, 06:48 PM
Seems there're somethings better than my version. http://stephantom2.st.funpic.de/experiments/php/array-js-php/array_test.php

http://magnetiq.com/2006/07/30/php-style-serialization-of-javascript-objects/

Twey
01-07-2007, 07:10 PM
So it doesn't initiate the statement right away? I'm really new to the final variable name, so I'm probably wrong.No, it means it doesn't do anything at all, but might do later if Ecma get around to it :)

mburt
01-07-2007, 07:24 PM
Yeah, I've fiddled around with ECMA script a little bit myself, and as far as I know, it works exactly like JavaScript, except with add-ons.

Twey
01-07-2007, 08:52 PM
ECMAScript is the standard to which JavaScript, JScript, ActionScript, and a few others conform.

jscheuer1
01-07-2007, 10:41 PM
To grasp what is going on with the 'final' keyword or whatever you want to call it in javascript, consider the history of the 'try' keyword. I think that this bit of reserving words is poorly thought out but, in javascript we now have the:


try{

}
catch(e){

}
finally {

}

construct. There was a time when we did not but, in browsers written before this construct became a part of the standard, all legitimate uses of try will cause a script to abort. That is because 'try' was reserved prior to its use in the above construct. They should have just left 'try' out of consideration entirely so that it could be tested for as an available method without causing older browsers to barf. The same (it appears) is true of 'final' except that nothing has been assigned to it yet, making all browsers 'older browsers' when it comes to its use as a variable. Stupid, if you ask me.

Twey
01-07-2007, 10:58 PM
... it could be tested for as an available method without causing older browsers to barf.How?

It's virtually impossible to test for a keyword, since the browsers that do recognise it will barf if it's used as an identifier anyway. About the only way of doing it is using try/catch with eval(), whose exceptions are not always fatal:
try {
eval("var final;");
} catch(e) {
// final is reserved (and thus implemented)
}However, since it's reserved without being implemented in the current state of affairs, we do the test the other way around:
try {
eval("final myvar;");
} catch(e) {
// We can't define final variables (so final isn't implemented).
}

jscheuer1
01-07-2007, 11:18 PM
I think you just answered your own question. There should be a better way, I agree. Ever since I found out about it, quite some time ago, I've always liked the 'typeof' construct. It should be able to be used in these instances but, as far as I know, it cannot.

Just as a footnote to the problems with 'try' - if you are determined to use it in code that you also want to be able to degrade gracefully to older browsers, there are established but somewhat elaborate and questionable (from the point of view of full future compatibility) ways of doing so. These involve using the archaic language attribute for alternate script blocks as well as filtering IE versions with conditional comments as, IE doesn't respect the language attribute conventions in place during the evolution of the use of 'try'. A real mess, if you ask me. In the end not even 100% but, very near so with existing browsers.

mburt
01-07-2007, 11:49 PM
I've always liked the 'typeof' construct
That tells you what type of data (variable name: boolean, integer, string, etc.) in the variable, not the type of keyword. Well, as far as I know.

jscheuer1
01-08-2007, 12:15 AM
That tells you what type of data (variable name: boolean, integer, string, etc.) in the variable, not the type of keyword. Well, as far as I know.

That's what I said but, why not? I mean why wasn't that included in its scope? Like:


alert(typeof try);

should return 'undefined' in browsers before try was instituted and 'reserved' or 'keyword' in browsers where try has been implemented. That way no reserving would ever be needed until a use for something was devised and implemented.

I realize that this would open up legacy code to errors in modern browsers but, that is already the case. I just think reserving words is a sort of anal compulsion on the part of the language developers with no thought as to how it will effect code written both before and after the reserved word finds a use.

Twey
01-08-2007, 04:54 AM
I think you just answered your own question.Aye, I know it's possible, but the way you put it made it sound as if it would be easier if older browsers didn't die on the keyword, whereas in fact the difference would be negligable.
They should have just left 'try' out of consideration entirely so that it could be tested for as an available method without causing older browsers to barf.The first piece of my code is what would be necessary to check for final if older browsers reserved it; the other is what's necessary as is. As you can see, both are pretty much equally ugly.

With regards to using typeof for keywords: it may be possible, but since keywords are part of the language proper, they're not objects; it would be very difficult to tell how the developer intended to use the keyword in a given situation.