Prototype JSON Evaluation Method

A simple function showing how Prototype can parse JSON

function parse_json()
{
   var data = '{"name":"value", "array_names":["Violet","June"], "key_array": {"red":"opens back door","blue":"opens front door"} }'.evalJSON();
 
   //json is the shiznit
   alert(data.name);
   alert(data.array_names[1]);
   alert(data.key_array['blue']);
}

Sample Prototype Ajax Function using JSON

Javascript:

function php_json()
{
    var url = 'json';
    var id = 0;
    var arrParams =
    {
        id: id,
    }
   
    var hash = $H(arrParams);
    var params = hash.toQueryString();
   
    var myAjax = new Ajax.Request(url,
    {
        parameters: params,
        //$('id_of_form_element').serialize(true),
        method:'post',
        onSuccess: function(transport)
        {
           
            strResponse = transport.responseText || "empty";
            strResponse = strResponse.replace(/[\r\n]+/g, "");
           
           
            if(strResponse != 'empty')
            {   
                data = strResponse.evalJSON();
                alert(data.key_array.red);
            }
            else
            {
                alert('strResponse is empty');
            }
        },
        onFailure: function()
        {
            alert('Something went wrong with changing the canceled status');
        }
    });
}

php:

public function json()
    {
        $this->render = false;
        $red = 'opens side door';
        $id = $_POST['id'];
        $json=END needs 3 < before END though, won't allow this in the editor
        {
            "name":"value",
            "array_names":["Violet","June"],
            "key_array":     {
                                "red":"{$red} {$id}",
                                "blue":"opens front door"
                            }
        }
END;
        echo $json;
    }

Thoughts on production environments with web applications

A good production environment

Environments:

PRODUCTION: normally the current live version

PRODUCTION_COPY - used to redirect live while development is being uploaded to regular PRODUCTION. This should reduce hiccups and keeps the site from being temporarily down for updates. Once copied over production

PRODUCTION_PREVIOUS: previous PRODUCTION environment before last changes were uploaded to production; created in case something wasn't caught in development and production needs to revert back to this while the problems are fixed in development.

DEVELOPMENT: Used for working on updates, after development is tested thoroughly and the client (if needed) has approved changes.

The environments above won't make the product foolproof (an error may not have been caught for several development phases), but at least it reduces errors in the live product.

Updates or project completed scenario:

1. Have QA or amateur testers view the project in the DEVELOPMENT version checking for problems. If no problems are found, move on.
   
2. Optional... maybe have several older productions, save PRODUCTION_PREVIOUS as PRODUCTION_PREVIOUS_001 - or the naming method you prefer.
   
3. delete all files in PRODUCTION_PREVIOUS
4. save PRODUCTION_COPY to PRODUCTION_PREVIOUS.
5. Redirect PRODUCTION to PRODUCTION_COPY
6. delete all files in PRODUCTION - make sure site is redirected to the copy
7. save DEVELOPMENT to PRODUCTION, make sure all files transferred.
   
8. Redirect live site to PRODUCTION once again.
   

Note: The steps above should be done for your files and databases.

Your project recently under DEVELOPMENT is now live and you have several steps to eliminate most errors and you have multiple backups.

Sample use for Environments

Main Site environments:

• mainSite
  
• mainSite_copy
• mainSite_previous
• mainSite_dev

Admin environments:

• admin
• admin_copy
• admin_previous
• admin_dev

maybe main and admin share things

• shared
• shared_copy
• shared_previous
• shared_dev