Archive for December, 2009

Parsing PHP in .html Files

December 9, 2009

Add/Append the following lines in you .htaccess file in your web server.

RemoveHandler .html .htm
AddType application/x-httpd-php .php .htm .html

Source

Advertisements

JavaScript 101: Creating a custom object

December 6, 2009

// initialize the object
var MyOwnClass = {};

// define all the members for the object
(function(){

// declare and define a property
var foo = “hello world! I’m foo.”;

// define a method
this.init = function()
{
alert(“yo! ” + foo);
}

}).apply(MyOwnClass );

// hook up with the DOM event
window.addEventListener(“load”, MyOwnClass.init, false);

“Error #1088: The markup in the document following the root element must be well-formed.”

December 5, 2009

I was using PHP and curl as proxy to get some xml files from Basecamp for my Flex UI to consume and was successful (something like “return $response¬†¬† = curl_exec($session);“. But after I refactored my little php functions into an object/class and included it in another delegation file, it suddenly stopped working. In Flex, I got the following error for the HTTPService fault event:

faultCode:Client.CouldNotDecode
faultString:’Error #1088: The markup in the document following the root element must be well-formed.’
faultDetail:’null’

In Firefox 3.5, the output XML file looked ok. But both Safari and IE gave error messages: There was an “*” in front of the <?xml ..?> header in Safari source code view; while IE gave the following error:

Invalid at the top level of the document. Error processing resource

After comparing the files before refactoring and the one after, I noticed that the refactored one was encoded in UTF-8 while the old one was in ANSI. After I converted my class file into ANSI, XML output became normal in all three browsers.

BTW, I used Notepad++. Not sure if that was an issue.

Anyhow, lessons learned: Make sure the source files are encoded in ANSI.

Any comments and thoughts are welcome!

Block statements in control flow constructs

December 2, 2009

There is no need to block (using braces to wrap) single line statements in a control flow (as-if, do-while, for/while); and you can mix blocks and non block statements together like this:

if(num > 0)
trace(num+” is positive;\n”);
else if(num <0)
{
trace(num+” is negative.”);
trace(num+” don’t be negative;\n”);
}
else if(num == 0)
trace(num+” is neutral;\n”);

This applies to all the control statements although the example here is just of if/else .

With this being said, The Elements of C# Style recommends Always us block statements in control flow constructs. Reason one is that it makes it easy to add additional statements in it; reason two is it’s easier to read than those without blocks.