cristobalnavarro
diff --git a/‎README.md
Lines changed: 1 addition & 1 deletion b/‎README.md
Lines changed: 1 addition & 1 deletion
diff --git a/‎dist/SerializerJS.js renamed to ‎dist/serializer-js.js b/‎dist/SerializerJS.js renamed to ‎dist/serializer-js.js
diff --git a/‎dist/SerializerXML.js renamed to ‎dist/serializer-xml.js b/‎dist/SerializerXML.js renamed to ‎dist/serializer-xml.js
diff --git a/‎test_html/demo.html
Lines changed: 3 additions & 3 deletions b/‎test_html/demo.html
Lines changed: 3 additions & 3 deletions
@@ -12,4 +12,4 @@ This project was written circa 2004, and is written in ES3 and fully compatible
 
 I was working at the time on a project for a client that needed a shopping cart. For some technical reasons that I forget the cart had to be made purely client-side, and post the results to the backend in XML. I needed some way of persisting my cart contents and save my JavaScript cart object to a string and store it in the cookie and then pull it out of the cookie when the next page loaded. Rather than solve this for just my case I took the generic approach. I reasoned that rather than store the JavaScript object in some custom format, or in JSON, which was new at the time, I'd store my JavaScript as, you guessed it, a string containing the JavaScript object. Then all I would need to do is call eval() on the object to deserialize it and recreate my shopping cart on the next page load.
 
-To go further I realized that when it came to posting the XML data back to the server in XML I could use a similar formatter to serialize the JavaScript object out to an XML string. This lead to the architecture of having a single Serializer.js file which accepts a JavaScript object and stores it, along with some type data throughout the object tree. I then wrote SerailizerJS.js which renders the object as a JavaScript string, and SerailizerXML.js which renders the object as XML.
+To go further I realized that when it came to posting the XML data back to the server in XML I could use a similar formatter to serialize the JavaScript object out to an XML string. This lead to the architecture of having a single serializer.js file which accepts a JavaScript object and stores it, along with some type data throughout the object tree. I then wrote serailizer-js.js which renders the object as a JavaScript string, and serailizer-xml.js which renders the object as XML.
@@ -1,9 +1,9 @@
 <html>
 <head>
 	<title>Javascript Serializer</title>
-	<script language="javascript" src="../dist/Serializer.js"></script>
-	<script language="javascript" src="../dist/SerializerJS.js"></script>
-	<script language="javascript" src="../dist/SerializerXML.js"></script>
+	<script language="javascript" src="../dist/serializer.js"></script>
+	<script language="javascript" src="../dist/serializer-js.js"></script>
+	<script language="javascript" src="../dist/serializer-xml.js"></script>
 	<link href="global.css" rel="stylesheet" type="text/css">
 <SCRIPT LANGUAGE="VBScript">
 <!--
Original file line number	Diff line number	Diff line change
`@@ -12,4 +12,4 @@ This project was written circa 2004, and is written in ES3 and fully compatible`
`12`	`12`
`13`	`13`	I was working at the time on a project for a client that needed a shopping cart. For some technical reasons that I forget the cart had to be made purely client-side, and post the results to the backend in XML. I needed some way of persisting my cart contents and save my JavaScript cart object to a string and store it in the cookie and then pull it out of the cookie when the next page loaded. Rather than solve this for just my case I took the generic approach. I reasoned that rather than store the JavaScript object in some custom format, or in JSON, which was new at the time, I'd store my JavaScript as, you guessed it, a string containing the JavaScript object. Then all I would need to do is call eval() on the object to deserialize it and recreate my shopping cart on the next page load.
`14`	`14`
`15`		`-To go further I realized that when it came to posting the XML data back to the server in XML I could use a similar formatter to serialize the JavaScript object out to an XML string. This lead to the architecture of having a single Serializer.js file which accepts a JavaScript object and stores it, along with some type data throughout the object tree. I then wrote SerailizerJS.js which renders the object as a JavaScript string, and SerailizerXML.js which renders the object as XML.`
	`15`	`+To go further I realized that when it came to posting the XML data back to the server in XML I could use a similar formatter to serialize the JavaScript object out to an XML string. This lead to the architecture of having a single serializer.js file which accepts a JavaScript object and stores it, along with some type data throughout the object tree. I then wrote serailizer-js.js which renders the object as a JavaScript string, and serailizer-xml.js which renders the object as XML.`