BLOG THIẾT KẾ WEBSITE

What to Do When You Get the "Ajax Call" from Your Boss

I admit it, I’ve never been a huge fan of JavaScript. I was always really glad that About had a JavaScript Guide so that I didn’t have to cover it on my site. I can read and write JavaScript, but until lately, I had very little interest in it. For whatever reason, my mind had a complete mental break when it came to writing JS scripts. I can write complicated C++ and Java applications and I can write Perl CGI scripts in my sleep, but JavaScript was always a struggle.

Ajax Made JavaScript More Fun

I think part of the reason I didn’t like JavaScript was because rollovers are boring. Sure, you can do more than that with JS, but 90% of the sites out there using it were doing either rollovers or form validation, and not much else. And once you’ve validated one form, you’ve validated them all.

Then Ajax came along and made it all new again.

Suddenly we had browsers that would support JavaScript doing something other than swaping images and we had XML and the DOM to connect data to our scripts. And all of this means that Ajax is intersting to me, so I want to build Ajax applications.

What’s the Stupidest Ajax Application You’ve Ever Built?

I think mine would have to be the email checker on an account that got almost no email. You would go to the Web page and it would say "You have 0 mail messages." The 0 would change if a message came in, but since that account got no mail, it would never change. I tested it by sending mail to the account, and it worked. But it was absolutely pointless. There were better mail checkers available five years ago, and I didn’t have to have Firefox or IE running to use them. When one of my co-workers saw it she said "What’s it do?" When I explained, she asked "Why?"

Before Building an Ajax Application Always Ask Why

Why Ajax?
If the only reason you’re building the application in Ajax is because "Ajax is cool" or "my boss told me to use Ajax," then you should seriously evaluate your technology choice. When you’re building any Web application you should be thinking of your customers first. What do they need this application to do? What will make it easier to use?

Why Not Something Else?
It can be very tempting to use Ajax simply because you can. On one site that my team was working on, there was a tabbed section of the page. All the content was stored in XML in a database and when you clicked on the tabs, Ajax was used to rebuild the page with the new tab data from the XML.

This seemed like a good use of Ajax, until you start thinking of some of the issues with it:

• The tabs cannot be bookmarked. So customers can’t save the information they want.
• Search engines don’t see the data that isn’t in the first tab, because they can’t access the Ajax.
• Ajax is not accessible, so the content in the other tabs would not be visible to anyone using a screen reader, or even older browsers that don’t have good JavaScript support.
• If one of the tabs had a lot of information, it could take a long time to load on a slow connection. And because Ajax doesn’t indicate anything is happening it looks like the page is broken.

The thing that was interesting, is that this Web site had similar pages in the past that didn’t use Ajax. They delivered the content either with hidden divs or separate HTML pages. There was no reason to use Ajax other than that Ajax was cool, and our boss had suggested we look for places to use it.

Ajax is for Action Not Content

If you’re going to put up an Ajax application, or just something Ajax-like on your Web site, first determine if the data you’re accessing changes. The point of the asynchronous request is that it makes requests to the server for information that has changed faster - because it’s happening while the reader is doing something else. Then when they click a link or button (or after a set amount of time - whatever your distinction is) the data shows up right away.

If your content or data never changes, then you shouldn’t use Ajax to access it.

If your content or data only rarely changes, then you probably shouldn’t use Ajax to access it.

Ajax

When you use Ajax to access the server without reloading the web page you have two choices on how to pass the information for the request to the server. These two options are to use GET or POST.

These are the same two options that you have when passing requests to the server to load a new page with two differences. The first difference is that you are only requesting a small piece of information instead of an entire web page. The second and most noticable difference is that since the Ajax request doesn’t appear in the address bar there is no noticable difference that your visitor will see on their screen when the request is made. Calls made using GET will not expose the fields and their values anythere that using POST does not also expose when the call is made from Ajax.

So how should we make the choice as to which of these two alternatives that we should use?

A mistake that some beginners might make is to use GET for most of their calls simply because it is the easier of the two to code.

The most noticable difference between GET and POST calls in Ajax is that GET calls still have the same limit on the amount of data that can be passed as applies when requesting a new page load. The only difference is that as you are only processing a small amount of data with an Ajax request (or at least that’s how you should use it) you are far less likely to run into this length limit from within Ajax to what you are with complete web page loads. A beginner may reserve using POST requests for the few instances where they do need to pass more information that the GET method allows.

The best solution when you have lots of data to pass like that is to make multiple Ajax calls passing a few pieces of information at a time. If you are going to pass huge amounts of data all in the one Ajax call then you would probably be better off simply reloading the entire page since there will be no significant difference in the processing time when huge amounts of data are involved.

So if the amount of data to be passed isn’t a good reason to use for choosing between GET and POST then what should we use to decide which to use? These two methods were in fact set up for entirely different purposes and the differences between how they work are in part due to the difference in what they are intended to be used for. This not only applies to using GET and POST from Ajax but applies to these methods where ever they are used.

The purpose of GET is as its name implies - to GET information. It is intended to be used when you are reading information to display on the page. Browsers will cache the result from a GET request and if the same GET request is made again then they will display the cached result rather than rerunning the entire request. This is not a flaw in the browser processing but is deliberately designed to work that way so as to make GET calls more efficient when the calls are used for their intended purpose. A GET call is retrieving data to display in the page and data is not expected to be changed on the server by such a call and so re-requesting the same data should be expected to obtain the same result.

The POST method is intended to be used where you are updating information on the server. Such a call is expected to make changes to the data stored on the server and the results returned from two identical POST calls may very well be completely different from one another since the initial values before the second POST call will be differentfrom the initial values before the first call because the first call will have updated at least some of those values. A POST call will therefore always obtain the response from the server rather than keeping a chached copy of the prior response.

So rather than choosing between GET and POST based on the amount of data that you are passing in your Ajax call, you should select between them based on what the Ajax call is actually doing. If the call is to retrieve data from the server then use GET. If the value to be retrieved is expected to vary over time as a result of other processes updating it then add a current time parameter to what you are passing in your GET call so that the later calls will not use an earlier cached copy of the result that is no longer correct. If your call is going to write any data at all to the server then use POST.

In fact you should not only use this criteria for selecting between GET and POST for your Ajax calls. You should use this as the criteria for choosing whether to use GET or POST when processing forms on your web page as well.

Ajax

One of the biggest advantages that Ajax has in web pages is that it can access information on the server without having to reload the web page. This means that to retrieve or update one small piece of information only that information needs to be passed to and from the server instead of having to redownload the entire web page.

There are two ways that Ajax can access the server. These are synchronous (wnere the script stops and waits for the server to send back a reply before continuing) and asynchronous (where the script allows the page to continue to be processed and will handle the reply if and when it arrives).

Processing your request synchronously is a bit like reloading the page but with only the requested information having t0o be downloaded instead of the entire page.

This method os therefore somewhat faster than not using Ajax since the information to be downloaded should be significantly smaller and hence faster to retrieve than downloading the entire page over again. It does however still require that your visitor wait for the download to occur. While your visitors are used to having to wait for entire web pages to download, they are not used to having to wait while interacting with a web page for any significant time and so unless the information you are requesting is particularly small so that it can be downloaded extremely quickly you run the risk of alienating visitors who may have been quite happy with a longer wait to download the entire page.

Processing asynchronously avoids the delay while the retrieval from the server is taking place because your visitor can continue to interact with the web page and the requested information will be processed with the response updating the page as and when it arrives. For larger requests where the response will have a noticable delay that delay possibly will not be noticed by your visitors because they are occupied interecting with fields further down the page. For responses that are nearly instantaneous your visitors will not even be aware that a request to the server was made.

The preferred way to use Ajax therefore is to use asynchronous calls where ever possible so as to enhance your visitors experience with the web page and to avoid having the Ajax interfer with the operation of the page. Using Ajax asynchronously is so obviously the right way that Ajax should be used that the A in Ajax is actually considered by those who consider AJAX to be an acronym to stand for Asynchronous (although the originator of the term claims that it is not an acronym and the letrters therefore don’t stand for anything).

If asynchronous calls are so much better for your visitor’s experience of the page than synchronous calls, why does Ajax provide a way to make synchronous calls at all? While asynchronous calls will work 99.9% of the time, there are rare situations where it just doesn’t make any sense at all to allow your visitor to continue interacting with the web page until a particular server side process completes. In many of these cases it may be better to not use Ajax at all and instead just reload the entire page. The synchronous option in Ajax is there for the small number of situations where you can’t use an asynchronous call and reloading the entire page is also inappropriate. There are not many such situations but they do exist and so Ajax provides for them.

A trap that many beginners may fall into is to use synchronous Ajax calls where asynchronous calls are more appropriate (as they are most of the time). The reason for this is that synchronous calls are easier to understand how the processing works. The thing is that asynchronous calls actually work exactly the same way except for the processing not waiting for the response but instead just handling the response when it arrives.

The only difference when using asynchronous calls is that you can actually set up multiple Ajax calls that overlap with a second call being made before the first has responded. This is where asynchronous Ajax does become slightly more complicated than synchronous Ajax because you need to make sure that each Ajax request uses a separate Ajax object rather than reusing the same object for all your Ajax requests. If you use the same object for multiple asynchronous Ajax calls then the response handler will only handle the first response that it receives and will disregard any subsequent responses. With overlapping Ajax calls with the same object you have no real way to tell whether the response that gets processed is a response to the first call or the second. By using separate objects for each Ajax call you will have a separate response handler for each request that will handle toe response from the request made by that object.

Using Ajax asynchronously is the better choice for most situations. If you are only making the one Ajax call from the page then it is no different in the way you code it to what you would use for a synchronous call except for the one parameter that identifies how the call is to be processed. With multiple Ajax calls on the same page, the only additional complication is that you need to create a separate Ajax object for each request. As the various Ajax libraries will all do this for you anyway the only time that coding your Ajax to use asynchronous calls will be any different from what you could get away with for synchronous calls is if you are coding all of the JavaScript for the Ajax calls yourself instead of using a library to do it for you.

Ajax

This page lists the available methods that can be used with date objects. Entries containing UTC refer to Coordinated Universal Time (UTC).

The UTC, FullYear, and Millisecond methods were added in Javascript 1.2

Get individual date and time fields.

Retrieve information about the date and time stored in a date object.

• getDay() integer value of day of week (0 - 6)
• getUTCDay() integer value of day of week (0 - 6)
• getDate() day of month
• getUTCDate() day of month
• getMonth() month of year (0 - 11)
• getUTCMonth() month of year (0 - 11)
• getFullYear() four digit year
• getUTCFullYear() four digit year
• getHours() hour of day (0 - 23)
• getUTCHours() hour of day (0 - 23)
• getMinutes() minutes into the hour
• getUTCMinutes() minutes into the hour
• getSeconds() seconds into the minute
• getUTCSeconds() seconds into the minute
• getMilliseconds() thousandths of seconds into the second
• getUTCMilliseconds() thousandths of seconds into the second

Set individual date and time fields.

Update the date and/or time stored in a date object.

• setDate() day of month
• setUTCDate() day of month
• setMonth() month of year (0 - 11)
• setUTCMonth() month of year (0 - 11)
• setFullYear() four digit year
• setUTCFullYear() four digit year
• setHours() hour of day (0 - 23)
• setUTCHours() hour of day (0 - 23)
• setMinutes() minutes into the hour
• getUTCMinutes() minutes into the hour
• setSeconds() seconds into the minute
• setUTCSeconds() seconds into the minute
• setMilliseconds() thousandths of seconds into the second
• setUTCMilliseconds() thousandths of seconds into the second

Other Useful Date Methods.

• getTime() milliseconds since midnight 1st January, 1970
• UTC() milliseconds since midnight 1st January, 1970 UTC
• getTimezoneOffset() minutes difference between local time and UTC
• parse() convert a date/time string into milliseconds since midnight 1st January, 1970
• toLocaleString() local date and time in string format
• toString() local date and time in string format
• toGMTString() converts a date to a string, using the Internet GMT conventions
• toUTCString() converts a date to a string, using UTC conventions

Chủ đề khác Học PHP Script

Chủ đề khác Học PHP Script

On our site, we have tutorials about adding data to a MySQL database, and tutorials about uploading files, but recently one of our forum users asked:

"I know how to submit data into a mySQL table through a form. Now I want to upload the image file to the remote directory (say, ‘images/’) but at the same time save the file-name in the table. "

This is a very common question because it has a lot of uses. Often you want a user to be able to upload a photo, but you don’t want to bog down your database space by saving all the images directly into the database. You instead save the image to your server, but keep a record in the database of what file was saved so you can easily reference the image when needed.

First let’s create a database:

CREATE TABLE employees (name VARCHAR(30), email VARCHAR(30), phone VARCHAR(30), photo VARCHAR(30))

This SQL code creates a database called ‘employees’ that can hold their name, email, phone and the name of their photo.

Creating a Form

<form enctype="multipart/form-data" action="add.php" method="POST">
Name: <input type="text" name="name"><br>
E-mail: <input type="text" name = "email"><br>
Phone: <input type="text" name = "phone"><br>
Photo: <input type="file" name="photo"><br>
<input type="submit" value="Add">
</form>

This is simply an HTML form that you would use to collect information to be added to the database. We could add more fields if we wanted, but then we would also need to add the appropriate fields to our MySQL database.

Processing the Data

<?php

//This is the directory where images will be saved
$target = "images/";
$target = $target . basename( $_FILES['photo']['name']);

//This gets all the other information from the form
$name=$_POST['name'];
$email=$_POST['email'];
$phone=$_POST['phone'];
$pic=($_FILES['photo']['name']);

// Connects to your Database
mysql_connect("your.hostaddress.com", "username", "password") or die(mysql_error()) ;
mysql_select_db("Database_Name") or die(mysql_error()) ;

//Writes the information to the database
mysql_query("INSERT INTO `employees` VALUES (’$name’, ‘$email’, ‘$phone’, ‘$pic’)") ;

//Writes the photo to the server
if(move_uploaded_file($_FILES['photo']['tmp_name'], $target))
{

//Tells you if its all ok
echo "The file ". basename( $_FILES['uploadedfile']['name']). " has been uploaded, and your information has been added to the directory";
}
else {

//Gives and error if its not
echo "Sorry, there was a problem uploading your file.";
}
?>

This code should be saved as add.php. To understand what each step of this script is doing it is best to read the comments within the code. Basically it gathers the information from the form and then writes it to the MySQL database. Once that is done, it saves the file to the /images directory (relative to the script) on your server.

If you are only allowing photo uploads, you might consider limiting the allowed file types to jpg, gif and png. We also don’t check if the file already exists, so if two people both upload a file called MyPic.gif, one will overwrite the other. A simple way to remedy this would be to simply rename each file with a unique ID.

 

Viewing Your Data

<?php
// Connects to your Database
mysql_connect("your.hostaddress.com", "username", "password") or die(mysql_error()) ;
mysql_select_db("Database_Name") or die(mysql_error()) ;

//Retrieves data from MySQL
$data = mysql_query("SELECT * FROM employees") or die(mysql_error());

//Puts it into an array
while($info = mysql_fetch_array( $data ))
{

//Outputs the image and other data
Echo "<img src=http://www.yoursite.com/images/".$info['photo'] ."> <br>";
Echo "<b>Name:</b> ".$info['name'] . "<br> ";
Echo "<b>Email:</b> ".$info['email'] . " <br>";
Echo "<b>Phone:</b> ".$info['phone'] . " <hr>";
}
?>

 

 

This script very simply queries the database and retrieves all of the information in it. It then echos each back until it has shown all the data.

To show the image, we just use normal HTML for the image, and only change the last part (the actual image name) with the image name stored in our database. For more information on retrieving information from the database, read this tutorial.

Chủ đề khác Học PHP Script

Previously in our script allowing files to be uploaded from the browser and saved to the hosting via PHP, we mentioned it was possible to rename the files to something random to prevent people uploading files with the same name and overwriting each other’s files. In this script we will explore that further.

<form enctype="multipart/form-data" action="upload.php" method="POST">
Please choose a file: <input name="uploaded" type="file" /><br />
<input type="submit" value="Upload" />
</form>

The first thing we must do, is allow the user to upload a file. We can do that by placing this HTML on any page we want to allow them to upload from.

This code is in a file separate from our PHP. It points to a file called upload.php, however if you save your PHP by a different name you should change it here.

Finding the Extention

Next we will use a function explained here, to look at the file name and take off the extension for us to use later when we reassign it a new name.

<?php
//This function separates the extension from the rest of the file name and returns it
function findexts ($filename)
{
$filename = strtolower($filename) ;
$exts = split("[/\\.]", $filename) ;
$n = count($exts)-1;
$exts = $exts[$n];
return $exts;
}

//This applies the function to our file
$ext = findexts ($_FILES['uploaded']['name']) ;

A Random File Name

Chủ đề khác Học PHP Script

The HTML Form

This script will allow you to upload files from your browser to your hosting, using PHP. The first thing we need to do is create an HTML form that allows people to choose the file they want to upload.

<form enctype="multipart/form-data" action="upload.php" method="POST">
Please choose a file: <input name="uploaded" type="file" /><br />
<input type="submit" value="Upload" />
</form>

This form sends data to the file "upload.php", which is what we will be creating next to actually upload the file

Uploading the File

The actual file upload is very simple:

<?php
$target = "upload/";
$target = $target . basename( $_FILES['uploaded']['name']) ;
$ok=1;
if(move_uploaded_file($_FILES['uploaded']['tmp_name'], $target))
{
echo "The file ". basename( $_FILES['uploadedfile']['name']). " has been uploaded";
}
else {
echo "Sorry, there was a problem uploading your file.";
}
?>

This very small piece of code will upload files sent to it by your HTML form.

The first line $target = "upload/"; is where we assign the folder that files will be uploaded to. As you can see in the second line, this folder is relative to the upload.php file.

Limit the File Size

if ($uploaded_size > 350000)
{
echo "Your file is too large.<br>";
$ok=0;
}

Assuming that you didn’t change the form field in our HTML form (so it is still named uploaded), this will check to see the size of the file. If the file is larger than 350k, they are given a file too large error, and we set $ok to equal 0.

You can change this line to be a larger or smaller size if you wish by changing 350000 to a different number. Or if you don’t care about file size, just leave these lines out.

.

Limit Files by Type

if ($uploaded_type =="text/php")
{
echo "No PHP files<br>";
$ok=0;
}

The code above checks to be sure the user is not uploading a PHP file to your site. If they do upload a PHP file, they are given an error, and $ok is set to 0.

if (!($uploaded_type=="image/gif")) {
echo "You may only upload GIF files.<br>";
$ok=0;
}

In our second example we only allow users to upload .gif files, and all other types are given an error before setting $ok to 0. You can use these basic examples to allow or deny any specific file types.

Putting It Together

<?php
$target = "upload/";
$target = $target . basename( $_FILES['uploaded']['name']) ;
$ok=1;

//This is our size condition
if ($uploaded_size > 350000)
{
echo "Your file is too large.<br>";
$ok=0;
}

//This is our limit file type condition
if ($uploaded_type =="text/php")
{
echo "No PHP files<br>";
$ok=0;
}

//Here we check that $ok was not set to 0 by an error
if ($ok==0)
{
Echo "Sorry your file was not uploaded";
}

//If everything is ok we try to upload it
else
{
if(move_uploaded_file($_FILES['uploaded']['tmp_name'], $target))
{
echo "The file ".

basename( $_FILES['uploadedfile']['name']). " has been uploaded";
}
else
{
echo "Sorry, there was a problem uploading your file.";
}
}
?>

Final Thoughts

Obviously if you are allowing file uploads you are leaving yourself open to people uploading lots of undesirable things. One precaution is not allowing them to upload any php, html, cgi, etc. files that could contain malicious code. This provides more safety but is not sure fire protection.

Another idea is to make the upload folder private, so that only you can see it. Then once you have seen what has been uploaded, you can approve (move) it or remove it. Depending on how many files you plan on receiving this could be time consuming and impractical.

In short, this script is probably best kept in a private folder. We don’t recommend putting it somewhere where the public can use it, or you may end up with a server full of useless or potentially dangerous files. If you really want the general public to be able to utilize your server space, we suggest writing in as much security as possible.

Chủ đề khác Học PHP Script, upload file, upload php

Chủ đề khác Học PHP Script

It may not seem like we have covered very much so far, but you may be surprised at what you’ve learned. Let’s review what we have studied in Lesson 1.

The contents of the Graphics Software site are copyright © Sue Chastain and About.com. These pages may be printed for personal reference, but they may not be distributed or republished for any purpose without prior written permission. Please see the About.com User Agreement for more information.

You learned how to find hidden menus and tools when you see a small arrow on a menu, palette, or tool button.

You learned how to identify many of the most commonly used keyboard shortcuts.

You learned how to take advantage of tool tips and hints in the status bar area.

You learned how to open a file.

You learned how to change the foreground and background colors, swap colors, and reset colors to defaults.

You learned how to change screen mode, as well as hide and show the toolbar, palettes, and menu bar.

You learned how to move, arrange, group, hide and show the palettes.

You learned how to access additional palette options through the palette menu.

You learned several ways to zoom in and out of documents.

Let’s review each of the keyboard shortcuts and commands we’ve discussed so far:

Zoom shortcuts:

• No modifier key = click to zoom in; click and drag to zoom into a specific area
• Ctrl-+/Cmd-+ (plus sign) = zoom in
• Double click the Zoom tool = zoom to 100% magnification
• Ctrl-Alt-0/Cmd-Option-0 = zoom to 100% magnification
• Double click the Hand tool = zoom to fit the screen
• Ctrl-0/Cmd-0 = zoom to fit the screen
• Alt/Option with zoom tool = click to zoom out
• Ctrl–/Cmd– (minus sign) = zoom out
• Type any number into the status bar magnifation level display.

Opening a File:

• File > Open
• Ctrl-O/Cmd-O
• Double click the application background (Windows Only)

Screen Mode and Display:

• F = toggles screen modes
• Shift-F = Turns menu bar on and off in full screen modes
• Tab = toggles the toolbox, status bar, and palettes on and off
• Shift-Tab = toggle only the palettes on and off

Palettes:

• Enter or Return = Show/Hide Options Palette (V5.x only)
• Double click tool button = Show/Hide Options Palette (V5.x only)
• F5 = Show/Hide Brushes Palette
• F6 = Show/Hide Color Palette
• F7 = Show/Hide Layers Palette
• F8 = Show/Hide Info Palette
• F9 = Show/Hide Actions Palette

Other Shortcuts:

• D = resets the foreground color to black and background color to white.
• X = swap foreground and background colors.
• M = marquee tool
• Shift-M = toggle rectangular and elliptical marquee tools

Học Photoshop