Category: Javascript

How to check for specific variables passed from previous pages using Javascript for your prototypes

I use this technique when I’m prototyping a multi-step form/application and I know what data I want to show on the page depending on whether I’m walking through scenario A, B, or C. It’s good in situations where you’re setting radio buttons on the previous page and just need to know which one was clicked. It’s lousy for situations where you don’t know what value your previous page might’ve sent. It’s best used when your “Review” and “Confirmation” pages are virtually identical except for one or two key pieces of data. There, it saves you time from building 3 review pages and 3 confirmation pages.

It is extremely breakable and probably shouldn’t be used in production code.

This uses forms submitted via GET so all the variables are in the URL.

First, on the page with the form, make sure the value you want to pass is in an input element in the form with a name (and the value) assigned to it. Input type=hidden is handy for this.

Second, make sure you’re submitting the form on the first page. Yes, this sounds obvious but when you’re prototyping sometimes folks take the quick way out and just code a button with a location.href Javascript on it, and that’s not a form submission.

Third, make sure that when you submit the form, the variable you want shows up as a name/value pair in the URL of the next page. That means the value is getting to where you’re going.

Now for the fun part. On the page receiving the value you need to do two things:

• Get the method out of the URL
• Tell the page to use it to do something

To get the method out of the URL, we do this:

function getMethod(){
var thisurl = window.location.href;
var locationOfValue = thisurl.search('TheValueYouAreHuntingFor');
if (locationOfValue = -1){
//write yourself an error condition handler in case your value's not there
} else {
//do the thing you want to do if you found it
}
}

(Please excuse WordPress’s built-in CodeMangler for the spacing…sigh)

So what’s that do exactly?

window.location.href grabs the href (URL) of the current window in string format so you can search it.

String.search(regex) tells you the position where a regular expression occurs in a string. If it’s not present, String.search() returns -1. So we take our string (thisurl) and search it for the value of the name/value pair we’re sending, and assign the result to a variable (locationOfValue). (Yes, you can definitely use shorter variables. This is a sanitized version of a function I’m using elsewhere. And it’s more readable this way.)

If locationOfValue is equal to -1 we didn’t find it. Either your value wasn’t passed correctly or you came into the page directly and the first page didn’t get the opportunity to pass anything. This is a good place to put a “if there’s no value here’s what I want you to display” clause.

If locationOfValue is NOT equal to -1 we found the value somewhere in the URL. Do whatever it was you were planning to do when you got it.

Obviously, once you have the tools to grab the location and parse it for a value or three, you can build more complex if/else if/else statements, but this is the simple version.

Now the final challenge is getting your page to call your function. Because we want to read in from the URL and use its results to modify the page, we want to throw a script block on the bottom of the page  that calls getMethod. Something like:

<script>
getMethod();
</script>

Write the page itself to be generic to whatever you want if it all crashes and burns spectacularly. (As they say on Mythbusters, failure is ALWAYS an option.) Then use the getMethod to read in your variables and modify your content accordingly.

I’ll try to build an example at some point soon.

*if you got the titular reference to the video game Catherine, w00t! Also, is that one creepy game or what?!

Let’s say you have a table of data, and you have a requirement to hide some or all of the data by clicking some “hide” or “show” links. If your data is only one-tier, it’s pretty easy to do. You can wrap the rows that you want to hide or show in a <tbody> tag and use that tag to make the rows it contains display or disappear. Here’s an example.

But while a <table> can have multiple <tbody> tags, they have to be stacked, they can’t be nested.

Good:
<table>
  <tbody>
    <tr>...</tr>
    <tr>...</tr>
  </tbody>
  <tbody>
    <tr>...</tr>
    <tr>...</tr>
  </tbody>
</table>

Bad:
<table>
  <tbody>
    <tr>...</tr>
    <tbody> <!-- ack! -->
      <tr>...</tr>
      <tr>...</tr>
    </tbody>
    <tr>...</tr>
  </tbody>
</table>

So what to do when someone designs a table that has multiple levels of expand and collapse and asks you to build it?

(A valid answer is “ask them if they really honestly truly need that much info at one time, because I mean c’mon really? There isn’t an information architecture solution better than that? Are they crazy?” but alas, sometimes that doesn’t cut it.)

If you knew that every time you needed to hide the subcategory’s rows you’d be hiding the same number of rows, you could write a function that accepted exactly that number of rows:

function hide3rows('ID1', 'ID2', 'ID3'){
  document.getElementById('ID1').style.display="none";
  document.getElementById('ID2').style.display="none";
  document.getElementById('ID3').style.display="none";
}

But I tell you as soon as you do that, some pest is going to come along and change the requirements to more rows or fewer rows, or sometimes six rows and sometimes eight. And you certainly don’t want to spend your time building a library of hide1row(), hide2rows(), etc. because you need that free time to follow around the person who wrote these requirements so you can keep asking them if they are in fact crazy.

This is where variadic functions come in. A variadic function is one that accepts a variable number of arguments. Generally, it does the same thing to all of the arguments, like add them together, or print them, or in our case figure out which elements they refer to and change their display attribute from visible to hidden. Different languages support variadic functions in different ways. JavaScript actually makes them pretty easy to use, by treating the arguments passed to the function like an array, so we can check the arguments/array length and iterate over its elements.

function hideThings() {
  for (var i = 0; i < arguments.length; i++) {
    document.getElementById(arguments[i]).style.display='none';
  }
}

Here’s our previous table modified to use this function.
Now we can call our hide function with as many or as few arguments as we need to hide. hideThings(‘mon’, ‘tue’, ‘wed’, ‘thu’, ‘fri’); is just as valid as hideThings(‘birthdays’); and we don’t need to clutter up our files with sixty five versions of the same function.

It seems like about half the world knows this one, but the other half doesn’t.

Let’s say you have a table, and you want to be able to toggle various rows on and off. So you write yourself a couple of simple Javascript functions to hide and show your stuff.

function hide(thingID){
document.getElementById(thingID).style.display = 'none';
}

function show(thingID){
document.getElementById(thingID).style.display = 'block';
}


Here’s the problem: display:block turns a table row into a block element — which is to say it compresses the whole table row into one big chunk and stuffs it into the space for your first table cell in that row.

If you do your research, you’ll quickly learn that the W3C says you’re supposed to use “display:table-row” for tables. But when you change your “show” function to use the preferred method, all the standards-compliant browsers start working, but IE 7 and the other annoying old IE browsers you’re forced to support just flat out drop the rows.

The secret? So obvious almost no one thinks of it until they’re told:

function show(thingID){
document.getElementById(thingID).style.display = '';
}


By setting the display to effectively “ain’t got one”, you tell the browser to display the row the way it would have if you hadn’t messed with it. Which results in what you were looking for:

To check the results in your browser(s) of choice, feel free to fiddle with this test page.