UseStrict Consulting

Professional IT Solutions & Training

Tag Archives: Javascript

Safari shows a blank page

I just ran into something odd and found all sorts of complex solutions (none of which worked for me), so I decided to post this case.

I’m creating a new version of an interface at work and tested with FireFox during development. When I opened it in Safari, all I got was the background image. No content at all. I Googled and several people reported having the same problem and said that clearing the cache would do the trick. It did not.

In the end, the issue was a missing ‘–>’ inside a script tag.

<script type="text/javascript"> <!-- // open a comment for older browsers - is this actually required still??
/* lots of JS here */

// There should be a close comment (-->)  here!
</script>

Safari, not finding the closing comment tag, simply considered all of the HTML to be commented out.

I hope this helps!

 

Book Suggestions:

 

Introduction to Ajax

In this article, I provide an explanation of Ajax with a historical introduction. If you are eager to start seeing the code, please scroll down.

 

What’s Ajax?

 

Ajax stands for Asynchronous Javascript And XML. It’s a way to call back-end scripts asynchronously – that is, without impacting user experience/flow. Basically, you don’t even see the cursor become an hourglass or whatever other “waiting/processing” icon your system uses. It’s not a language, but a technique. As for back-end scripts, you can use whatever you feel more comfortable with: PHP, Perl, Java, JSP, Shell, C, etc. The way to choose which technology to use as back-end is not outside the scope of this article.

 

Historical approach for calling back-end apps

 

Throughout web-development history, the very first way used to achieve back-end processing followed by front-end display was to create a form and set the back-end script as the action to that form. Upon submission, the form fields would be sent to the back-end script as a series of special environment variables, which would then be handled by the programmed logic. The back-end output would be displayed on the screen (either the same page/frame or a different page/frame, depending on the target attribute of the form).

The catch 22 of this approach is that if you want to present another form after processing, that form must be produced by the back-end script, which leads to maintenance mayhem – to add or remove a field, you have to do so in both the original HTML and in the HTML of the back-end script.

Continue reading →

Ajax: Form fields into URL query string

Here’s a quickie for you Ajax coders who need a function to parse your form fields into a URL query string. It handles input fields (text, hidden, whatever), radio and checkbox elements, and single/multiple select menus. Just make sure that all your form fields have IDs. Multiple choice SELECTs get grouped by pipes (|). Update:Modified multiple-choice SELECTs to work like real GETs.

function build_post_string(frm) {

	var poststr;
	var poststr_array = [];

	if (!frm.id) {
		// assume it's a string. get the form object
		frm = document.getElementById(frm);
	}

	for (i=0;i<frm.elements.length;i++){

		var elem = frm.elements[i];

		if (!elem.id) {
			// skip any fields that don't have IDs
			continue;
		}

		if (elem.type == 'radio' || elem.type == 'checkbox') {
			// only grab radio buttons and checkboxes that are checked
			if (!elem.checked) {
				continue;
			}
		}

		// get select values
		if (elem.nodeName.match(/SELECT/i) && elem.multiple) {
			//var sel = elem;
			var sel_array = new Array();

			for (var o=0;o<elem.options.length;o++) {

				if (elem.options[o].selected) {
					sel_array[sel_array.length] = elem.id+"="+elem.options[o].value;
				}
			}

			var sel_str = sel_array.join('&');

			// build key/value pairs for SELECTs
			poststr_array[poststr_array.length] = sel_str;
		}
		else if (elem.nodeName.match(/SELECT/i)) {
			poststr_array[poststr_array.length] = elem.id+'='+elem.options[elem.selectedIndex].value;
		}
		else {
			// build key/value pairs for everything else
			poststr_array[poststr_array.length] = elem.id+"="+elem.value;
		}

	}

	// build poststr
	poststr = poststr_array.join("&");
	return poststr;

}

 

Book Suggestions:

 

Perl Crash Course: Introduction to Perl

Perl – the Practical Extraction and Report Language (or Pathologically Eclectict Rubbish Lister) was created by Larry Wall in the late 1980′s. It started as a combination of Larry’s favorite Unix tools such as sed, awk, and shell, and grew to be the best language for text manipulation.

I started learning Perl back in 1998 by myself. What made it possible for me to do that was that Perl scripts, like shell scripts, are not compiled binaries. You can open it with a (good) text editor and see exactly what the programmer did to make it work. Same thing with HTML, JavaScript, CSS, and all other democratic languages around. No reverse-engineering needed.

Speaking of Web technologies, Perl was considered SO GOOD with manipulating texts, that it was once the #1 language for CGIs. For those of you who don’t know, CGI stands for Common Gateway Interface and it was the way websites could show dynamic data back in the early days of the Internet. In fact, Perl was so popular with CGIs, that many people didn’t (and still don’t) know it could do anything else. On the contrary, although Perl has excellent Web modules such as Catalyst, Template::Toolkit, HTML::Mason, and so many others, it’s not my first choice for Web development (for reasons that are not in the scope of this course). However, I can’t live without it for anything else.

Perl is portable: you can write one script and run it in just about any Operating System that has a Perl interpreter installed. And you can find Perl interpreters for practically all the OS’s around.

Perl is fast: although the Perl interpreter needs to read, parse, compile, and run the script on every execution, it’s still VERY fast by any standard.

Perl gets faster: there are ways to bypass the first 3 stages of the Perl execution, either by using mod_perl for Apache, or by using the Perl Archive Toolkit, which gives you a precompiled (albeit potentially large) binary of your script.

Perl is Object Oriented: ok, that didn’t sound right. Perl can be used from either a procedural or an object oriented scope. In real world applications, you’re likely to mix both cases to suit your needs.

Perl is extremely high level: this means that given the statements in your script, you are likely to be able to read them as you would plain English. This was done on purpose, of course, given the fact that Larry Wall is a linguist.

Perl is free: you can download it with no cost from several distributors, install, and use for any purpose – commercial or otherwise and not have to worry about licensing.

Perl is free form: you can write the code practically in any way you like and get away with it. This is great as long as you keep in mind that writing good code also means writing clean code. You can seriously hurt your foot if you’re not careful. Obfuscation is only fun when it’s intentional.

I can go on forever telling you all that Perl can do, especially if I decide to talk about CPAN, the Comprehensive Perl Archive Network – a website with over 10,000 modules for everything you can think of, from complex math and graphic manipulation to fooling around with the Klingon language. You can even use the Perl/Tk to create graphical user interfaces.

If what I said so far was enough to interest you to learn Perl, then keep on reading. There’s something to the language that feels almost addictive, if you don’t let all the non-initiated folks make up your mind against it…

« TOC | Getting it installed on… »