Amass

Rewriting my Javascript

February 6th, 2007 Luke

A friend and I are busily sketching out a project idea that, among other things, involves a countdown. For a while, I couldn’t figure out how to do it. But after giving it a little bit more thought, I realized that all we’d need is a little bit of javascript and an initializing function that would begin the countdown, along with refreshing the page when the countdown was finished(most of the real ‘actions’ per se are run by server-side code, not client-side).

This was all well and good, and last night I happily sat down and hacked out a solution. You can see it in the portfolio section of girasquid.com. And it works, and it does what it needs to.

But at the same time, it’s not as … robust as I’d like it to be. It doesn’t do all the cool things. It won’t let me put more than one countdown on a page without hard-coding that. It won’t let me spawn off lots of countdowns at once with all different times, and then independently start and stop them.

For some of my projects, I encounter a problem like this and just go “oh. Well. I’ll do that later.”, and put it on my “torewrite” list(which is growing rather large, unfortunately). But this is a piece of code that’s generally useful, and I think that if I could develop it further so that it was perhaps object-oriented and more flexible, other people would use it. And that would be sweet. Therefore, I’m in the process of redesigning it. This is what I’ve sketched out.

We would have a Countdown object. It would have different member variables, that would make it easy for a separate script to interact with it’s parts. These are the variables and their breakdowns:

  • itsHours
    • - the number of hours remaining in the countdown.
  • itsMinutes
    • - the number of minutes remaining in the countdown.
  • itsSeconds
    • - the number of seconds remaining in the countdown.
  • itsCounting(boolean)
    • - whether or not the counter is actually moving or not
  • itsRemainingSeconds
    • - the number of seconds total(hours + minutes + seconds)
  • itsRedirect
    • - where to redirect the user to, once our countdown has finished(refresh/no action if empty)
  • itsInterval
    • - the interval we were using to continuously update our timer.

And then we would have different methods that we’d be able to call to actually do our counting. Here’s a sketch so far:

  • initialize(seconds,redirect)
    • - This creates a Countdown object for us, and sets the two member variables we’re supposed to be able to set.
  • start()
    • - this would actually start the countdown, along with setting itsCounting to true.
  • stop()
    • - this would stop the countdown at the second it was currently at, and set itsCounting to false.

There would also be multiple utility functions for things like making sure the hours/minutes display correctly and such. I’m planning on introducing one function that lets a user pass in a string with certain placeholders, and have the object return the string, with the placeholders filled in with their respective values. That would be cool.

I’m going to get to work on this.

Posted in javascript, rewrite | No Comments »

On-demand Javascript: Testing for functions

February 3rd, 2007 Luke

Recently, I’ve been taking a look at some of my projects and considering how they load in their data. At this moment, both Bear and Parakeet load in all of the Javascript and CSS files that they need the moment they are called. If a person visits the Bear page and goes to their shop but doesn’t actually use the combat interface, we’re still loading in all of the combat interactions. This is a Bad Thing™, because it’s more than doubling the bandwidth used for things that a user might not even be doing.

So, along those lines, I opened up Google and began researching “Javascript on-demand”. It seems that there are two different ways to do this: one method uses xmlHttpRequest and allows for feedback(things like loading messages), and the other uses the DOM and is a little bit more difficult to do feedback with. It’s still possible, but not as cleanly.

For that reason, I’ve decided that when I need to load my javascript on demand, I am going to use xmlHttpRequest. However, there’s still a problem: how do I prevent myself from loading in the same javascript file multiple times, every time the function that originally loads it in is called?

I’ve managed to figure out a solution to this, and that solution is in testing for a function. Here’s my sketch of how to do it(mostly untested):

First off, we’d have an XML file storing all of our ‘load in javascript files for this’ functions. Any function that wasn’t contained within our initial library of javascript would be loaded in dynamically for us. The XML would be outlined like this: <function> <name>myFunction</name> <path>lib/myfunction.js</path> </function>

Then whenever we called a function, our library would first run this test: if(self.functionName) { // In this case, we already have the function present. // Therefore, just call it. functionName(args); } else { // In this case, the function does not 'exist' yet. We need // to figure out what it's path is, and then load it in }

In the second case, we would just loop through our XML file, looking for something with a ‘name’ attribute matching that of the function we’re looking for. Then we would just retrieve the path info and load the file in, and we’d be ready to go. This solution cleanly allows us to load in javascript on-demand and have feedback while doing so, along with making sure that we don’t accidentally load any files in twice. This saves on bandwidth, and makes it easier for us to keep all our code more organized.

Posted in javascript, webdev | No Comments »