I could easily loop through the array and create an HTML table, or some other visually readable HTML layout to examine and update the data, but that would be a lot of work. Not only would I have to code the HTML table layout (from the PHP array), I’d have to build in some sort of update mechanism to save the data back to the server.

Since this was intended for developers to access (and not average users), I didn’t really need to make it user-friendly, but I wanted it to at least make it developer-friendly.

So my thought was to just display a JavaScript object (which is human-readable by nature) that can be modified directly (perhaps in a <textarea> or something like that), and then be able to save the entire modified JavaScript object back to the server, as is. Since PHP can easily read a JSON string and convert it to an object (which is what I wanted in the end), this seemed to be the quickest approach.

The problem

I was having a hard time with the following:

1. Converting the PHP array into a valid JavaScript object. I could easily convert it to a JSON string (using json_encode($array)), but I didn’t want a JSON string – I wanted a literal object in JavaScript.
2. Displaying the JavaScript object in a readable fashion (broken out on separate lines, as opposed to everything on one line). json_encode($array) would provide me the string to display, but it put everything on a single line, making it very difficult to read.

Here’s an example PHP array:

$array = array(
  "key1" => array(
    "key1a" => "value1",
    "key1b" => "value2",
  ),
  "key2" => "something",
);

… and how I wanted it to look in the browser (inside a <textarea>):

{
  "key1": {
    "key1a" : "value1",
    "key1b" : "value2"
  },
  "key2": "something"
}

The solution

In PHP, first encode your array into a JSON string:

$json_string = json_encode($array);

// above will result in:
// {"key1":{"key1a":"value1","key1b":"value2"},"key2":"something"}

Then in JavaScript, parse the JSON string into a JavaScript object (using jQuery):

var json_object = jQuery.parseJSON('<?php echo $json_string; ?>');

Then (also in JavaScript) convert the JSON object into a “pretty” string:

var json_string = JSON.stringify(json_object, null, 2);

Write it to the DOM:

<textarea name="data_json" id="data_json">

$("#data_json").html(json_string);

This will make it readable and editable. Example:

{
  "key1": {
    "key1a" : "value1",
    "key1b" : "value2"
  },
  "key2": "something"
}

Then when saving it back to the server, PHP can once again convert it to an object so the data can be easily processed:

$data = json_decode($_POST["data_json"]);

This is important to know when trying to declare HTML element attributes using JavaScript object.property syntax.

For example, let’s say I want to create this HTML element using JavaScript:

I can’t do something like this:

var div1 = document.createElement("div");

div1.class = "one";

The word “class” is reserved in JavaScript, and although you’re intention is to declare the HTML elements’ “class” attribute, this won’t work.

Instead, you need to do this:

div1.className = "one";

“className” is a subtle alternative that will apply the “class” attribute to any HTML element.

Side-note: I don’t quite understand why it’s called “className,” when “classAttributeValue,” or “classValue” would make more sense.

HTML “for” attribute

Another tricky HTML element attribute to declare in JavaScript is the “for” attribute, which is used in the element. For example:

Check One

In JavaScript, we can’t do this:

var label1 = document.createElement("label");

label1.for = "one";

“for” is also a reserved JavaScript keyword.

I bet you’re guessing we need to use forName in JavaScript? Unfortunately, this naming convention is not applicable to any attribute.

Instead, we can try something like this:

var label1 = document.createElement("label");

label1.setAttribute("for", "one");

This seems to work fine in most standards-aware browsers, but Internet Explorer 8 does not seem to support it, so at the moment it’s not a universal solution.

If anyone has another work-around for this, please help resolve this “pain.”

The most commonly used approach looks something like this:

Link

Here we use a “pound” or “hash” character as the href value. This is because we need to put something in there, but we only care about the onclick event firing. Turns out this is not the best approach because it fails to do anything if JavaScript is turned off.

Ideally, you should provide a real location as the href value:

Link

The above approach is safer, because if JavaScript is turned off, the browser will simply go to page.htm, and ignore the onclick attribute.

my_function() could then look something like this:

function my_function()
{
    window.location = "page.htm";
}

With JavaScript turned on, the browser acknowledges the onclick attribute. We also add return false; inline, so the link does not go anywhere until we explicitly tell it to within the my_function function. This is useful in case there are reasons we’d like to stop the link from working – perhaps there is a user-submitted error on the page that needs to be corrected before proceeding.

Same for


This approach should be consistent when handling HTML forms.

Again, if JavaScript is turned off, the form submits to page.php right away, where we’d process the form details. If JavaScript is turned on, we first run a validation function to ensure the form values are accurate before submitting to the server:

function validate()
{
    var my_form = document.getElementById("my_form");

    my_form.submit();
}

Here we submit the form via JavaScript, but only if it’s passed all of our validation tests. If not, we just don’t run this line:

my_form.submit();

If that line is not run, the function will return true, then it will see the return false; inline, and stop everything. This is what we want, because we want to stop everything if the form should not be submitted.

Keep in mind, when handling submitted form data, you should always validate both client and server side. So, even if they pass the JavaScript validation tests, those same checks should be applied in the PHP page.

Although, I don’t like having to manually click on the bookmark before typing in my keyword search, but I suppose I could get used to it. The nice part about Firefox keyword search is that it allows you to use the address bar, which is where you’d type in your URL anyway.

However, I like the idea of having my keyword searches accessible regardless of the current browser I am using. In a way, this makes my keyword bookmarks portable and future-proof.

Also, it’s an absolute must for iPhone/iPod touch users. It will save time typing, as well as reduce page loading time over the slow EDGE network, by bringing you directly to the search results page, rather than first going to the search page, then the results.

Create your own custom Shortwave

Creating your own Shortwave is easy. Just download the default waves.txt file, edit it with your own bookmarks, then upload to a web server of your own.

Go back to the Shortwave home page, and paste the URL to your waves.txt file into the box.

Sync your iPhone/iPod bookmarks

On your desktop Safari, drag the Shortwave bookmark to your bookmarks toolbar. In iTunes, sync your bookmarks to your iPhone or iPod touch.

You’ll then have a JavaScript-prompt bookmark saved on your mobile device, ready for your keyword searches.

• Avoid using feeds as content.
• Trying too hard to merge content.

Flash and JavaScript widgets are tacky, gaudy, and unprofessional. I’ve experimented with widgets before, but lately I’ve been feeling they cause more harm than good.

Depending on what kind of personal site/blog you are running, you may want widgets floating all over the place. Heck, I’ve seen some pretty effective sites with only one or two widgets.

But in most cases, widgets only “booger up” a web page. It’s almost like sticking “Intel Inside” stickers all over your computer.

Widgets promote a more cluttered look, often break HTML layouts, and reduce page loading speed.

Oh, and there’s plenty more reasons why they suck.

Any ideas on a solution to this problem? Should sites allow API’s, rather than widgets?

Here’s an example of something I recently created that illustrates my point:

Get the Flash Player to see this player.

These “dynamic form elements” are written to the page only when the user performs a certain action; in this case: clicking on a table cell.

The HTML for the table cell could look something like this:

$1.55

Once the user clicks on a cell, the HTML of the cell changes to:

This gives the user a text box with which to edit the value.

In order to do this, you’ll need a quick way to remove any existing child nodes of the table cell.

There are many ways to do this in JavaScript, but I’ve discovered one that seems to work in all types of situations:

var cell = document.getElementById("cell");

if ( cell.hasChildNodes() )
{
    while ( cell.childNodes.length >= 1 )
    {
        cell.removeChild( cell.firstChild );       
    } 
}

No matter how many nested nodes exist, it removes them all. Quite handy.

First off, I’ve discussed Twitter before, and I still stand by my positive opinions. I did, however, have a small issue with posting yet another JavaScript badge onto my site.

It seems this is a current trend that can’t be avoided (at least, not avoided painlessly), so I am going to just do it, for now. I already have a couple JavaScript badges on my front page: the Google Reader Shared Items (“What I’m reading today…”), and my five most recent Flickr photos. I was hesitant to add yet another.

So what are my issues with JavaScript badges? I’ll let Jeremy answer that one, but in a nutshell:

• Slower page loading time.
• Search engines can’t “see” this included content.

The “slower page loading time” is due to the JavaScript badge making an external server call, each time the page is loaded. What happens when the external server is down? My site fails to load. This “reliance” on a third-party application is unsettling at best.

The biggest complaint is that search engines can’t “see” JavaScript badge text, so therefore it’s like the content doesn’t even exist on my site.

This complaint can be argued back and forth endlessly, because some people believe that web sites should be made for visitors, not search engines. Google even says so:

Make pages for users, not for search engines.

I agree with this sentiment, so that’s why I decided to just ignore my “gut instinct” for now.

....



    





    



....

This provides each
with a unique ID (id attributes must be unique, anyway), so you can now target specific table rows with JavaScript.

Problem is… how do you know which rows are pulled? In other words, when the page loads the dynamic content, JavaScript won’t know which unique id’s are actually residing in the DOM.

Proposed definition of “dynamic”: could change.

Pull all
elements

JavaScript typically targets specific elements using getElementById(). We won’t be able to use this, because we don’t know the id’s on the page. Instead, let’s use getElementsByTagName().

getElementsByTagName() does just what it sounds like – it gets all elements using a certain tag name.

var allTrElements = getElementsByTagName("tr");

This will grab all
elements, and store them into an array, which we can then loop through to perform additional programming.

Problem solved?

Not quite. getElementsByTagName("tr") will pull all
elements on the page, including ones you may not want or need access to.

So how do we pull only the
elements from the specific table with the database rows?

Pull only certain
elements

We can look at the id attribute, and base it off that. If the id attribute starts with “myRow” – then we know that’s a
we want to work with.

// STORE ALL  ELEMENTS IN AN ARRAY.

var allTrElements = getElementsByTagName("tr");


// LOOP THROUGH ALL  ELEMENTS ON THE PAGE.

for ( var i=0; i < allTrElements.length; i++ )
{

    // SET THE CURRENT  ELEMENT TO A VARIABLE.

    var tr = allTrElements[i];


    // IF THE CURRENT  HAS AN id ATTRIBUTE
    // THAT BEGINS WITH "myRow", THEN PROCEED.

    if ( tr.id.substr( 0, 5 ) == "myRow" )
    {

        // EXTRACT THE id NUMBER OFF OF THE id ATTRIBUTE.

        var rowId = tr.id.substr( 6 );


        // TARGET THE SPECIFIC ROW.

        var rowTarget = document.getElementById( "myRow_" + rowId );


        // DO SOMETHING SPECIFIC TO THE ROW.

        rowTarget.className = "highlight";

    }

}

So, using the id attribute of the
element, we can throw away the
elements that we don’t want to target, as long as each id is named consistently.

Using this method, all I have to do is apply an attribute of rel="external" to any link that I wish to open in a new browser window. To me, this is much more preferable (and standards-compliant) than using target="_blank".

The JavaScript function (obtained from Sitepoint) that controls this is relatively straight-forward. I also made an addition to the function that controls links that you want to open in the same external browser window. In other words, you open the external window once, and then every additional link opens in that same external window (as opposed to a new window each time).

function externalLinks()
{
    if (!document.getElementsByTagName) return;

    var anchors = document.getElementsByTagName("a");

    for ( var i=0; i < anchors.length; i++ )
    {
        var anchor = anchors[i];

        if ( anchor.getAttribute("href") && anchor.getAttribute("rel") == "external" )
        {
            if ( anchor.getAttribute("className") )
            {
                anchor.target = anchor.getAttribute("className");
            }
            else
            {
                anchor.target = "_blank";
            }
        }
    }
}

For explanation on how the function works, please see the original Sitepoint article.

My addition, which is not part of the original script from Sitepoint, is in bold. It checks to see if the class attribute is set for the element. If so, it uses that class attribute value as the name of the external window. So, as long as every link (that you wish to have open in the same external window) has the same class attribute – all of those links will open in the same parent window.

Link 1

Link 2

Link 3

Here are two more links that will open in an external window, but not the same one as the above three links:

Link 4

Link 5

Notice the class attribute value has changed in Link 4, and the class attribute doesn’t even exist in Link 5.

Cautions

This entire script has only been tested in Firefox 1.5.x for Windows, and Internet Explorer 6.

There is also the slight problem of window focus. For example, if I click on a link that uses an existing window as it’s destination, the focus should be placed on that window. It is currently not happening that way.

Additions to this script may be made over time.

    onclick="do('Do This')" value="Do This"> Do This 
    onclick="do('Do That')" value="Do That"> Do That 

This is aggravating, when you need to perform a certain function, dependent upon each option chosen from the list.

For example, if someone chooses “Do This” from the select list, I need a certain function to run. However, if someone chooses “Do That” from the select list, I need a different function to run.

Turns out IE only recognizes onchange.

So, instead of applying an onclick to each
element, we’ll apply a single onchange to the entire select list:

onchange="do( this.value )">

     Do This 
     Do That 

The JavaScript do function could look something like this:

function do( optionValue )
{
    switch( optionValue )
    {
        case "Do This" :
        
            // SPECIFIC CODE HERE
        
        break;
        
        case "Do That" :
        
            // SPECIFIC CODE HERE
        
        break;
    }
}