Archive for the ‘JavaScript’ Category

JavaScript without the Script Blocks

June 29th, 2007 by ScottK | No Comments | Filed in JavaScript

Here’s the problem, a web site allows you to use html but filters script blocks. You really want to use some cool javascript though.

How to you do it?

Use an anonymous javascript function on the onload event of an image. If you read my article about WEDJE and/or Mike Davidsons’ article about the same you’ll see the basic format for setting up script for slow loading servers without stopping a page load. Based upon that knowledge I decided to take it a step forward. As I normally do.

Testing in all browsers show that they support the onload event for and image tag. What this means is if the image was successfully loaded then the onload event is triggered. So we’ll use that to call an image off our server but for everyones sake I’ll replace the onload with onclick for demo purposes.

<div id=”needed_script_container”></div>
<img src=”http://www.techraving.com/images/ror.gif” border=”0″ onclick=”" />

Having that basic setup let’s add the base javascript to call our external javascript file using the anonymous function to create a script element dynamically.

<div id=”needed_script_container”></div>
<img src=”http://www.techraving.com/images/ror.gif” border=”0″ onclick=”(function() { s=document.createElement(’script’); s.type=’text/javascript’; s.src=’http://www.techraving.com/javascript/anon.js’; setTimeout(’document.getElementById(\’needed_script_container\’).appendChild(s)’, 1); })()” />

The reason the div is needed is to attach the new script element. The setTimeout is to delay the attachment of the element just a little to make sure the page has successfully loaded it. For slower sites the timeout can be increased.

Now with that code placed in a webpage and clicking the graphic the onclick event is triggered and activates the inner javascript. Dynamically creating the seed script block with the div means that further javascript functions can now be used.

Using the above code click the image below to see it in operation:

The called javascript file merely includes: alert(”This page location: ” + window.location.pathname + “. I am glad to meet you!”);

So far I’ve found no real reason to use this, yet! But hey now we know right! :)

It’s JavaScript, Who Gives a Crap

June 10th, 2007 by ScottK | No Comments | Filed in JavaScript

I’ve had the opportunity to work on client side programming for several different companies over the past few years and I’m a bit upset. In each I’ve heard the call to implement the software in Model-View-Controller, n-Teir, etc architecture. Full testing suite of all code. Code reviews and regretion testing. Yada yada yada.

This is on server side code only! Each opportunity also required web 2.0 interfaces through JavaScript. One application had nearly a thousand js functions and the application wasn’t close to being done when my contract was up. None of the project managers cared to test the JavaScript to make sure it worked. For whatever reason client side programming isn’t within the code management criteria.

I always chuckle silently when I hear people talking about testing and such for server side code. JavaScript is programming as well. Incorrect use of it not only brings down the use of the application and potentially brings down a users external web site that is using your code.

Because I truly believe that many “programmers” and “program managers” completely mis-understand JavaScript and how powerful it can be in educated programmers hands; and that they also don’t realized that testing is available. There seems to be a xUnit tester for every language out there and JavaScript is no exception. JsUnit is an open-source application for JavaScript testing.

It can be run without a web server but have found that file permissions on Windows systems interfer with this. So I run it as a web application just fine. Simply give it the url for the test page and let it run through your tests. Even comes with a stack trace to find out where it bombed at.

So to all who mandate software control without giving consideration to JavaScript I say shame on you. It’s a language, it has design and archetecture. It can bring down your application if not controlled.

Interfaces for JavaScript Classes

March 22nd, 2007 by ScottK | 1 Comment | Filed in JavaScript

Well based upon my continuing work with JavaScript I had to try and create an interface type system for JavaScript classes. By doing so I can still hold to OOP principles and only allow a class to be used through an interface. Thus keeping the class hidden.

The long story short is that I was able to create an interface but not traditionally by mandating that the class use it. Basically the interface had to create an instance of the class then pass through to the classes public methods. By doing it this was performance will be reduced and no real gain of code control.

I’ll keep playing with this but it doesn’t look like it’s a viable option with JavaScript.