Wednesday, April 2, 2008

GET or POST

From Stephen Chapman


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.

Monday, March 17, 2008

9 Practical Ways to Enhance your Web Development Using the Firefox Web Developer Extension

Whether you’re a front-end graphics designer or a back-end web programmer, if you’ve worked long enough in the field of creating web-based solutions, you’ve no doubt heard about an extension for the Mozilla Firefox web browser called (simply enough) the Web Developer extension. If you have no clue what I’m talking about, here’s a brief overview from Webs Tips to get you familiarized with this wonderful tool.

A screenshot of the Mozilla Firefox Web Developer tool

This article lists some practical, everyday uses of the Web Developer extension to help improve your web-building methods. I’ve tried to stay away from the more common and basic uses of the Web Developer extension like troubleshooting layout issues with the Information > Display Div Order option because I feel these have been discussed quite enough in other places. New users, don’t run away quite yet, I think this guide will help you get a rapid jump start into applying this tool into your daily development routine.

So without further ado, here’s nine highly pragmatic uses of the Web Developer extension for Firefox.

1) Change XHTML on-the-fly without changing your web files.

Unfortunately for many developers, we don’t all have the luxury of testing servers and sandbox environments. I for one, confess to developing on live websites even during peak web traffic times.

If you’d like to lessen customer support requests due to an inadvertent display:none; property assignment on the log-in box — use the Web Developer extension to effortlessly check your XHTML modifications before you commit them to the server.

Here’s an (extreme) example of how I was able to change a few of reddit’s XHTML markup.

The original front page:

Screenshot of reddit's front page before editting XHTML markup.

And here’s the modified version:

Screenshots of reddit's front page after changing some XHTML markup.

As you can see in the above picture, I changed the top three stories (to something else I’d much read about) and modified the background color to pink (I have an odd affection towards hot pink for some reason).

You can achieve the same results by using the Miscellaneous > Edit HTML Markup option which will open up the Edit HTML tab panel displaying the XHTML of the web page. Unfortunately, the window isn’t color-coded and the Search HTML function doesn’t quite work properly (yet).

A screenshot of the Edit HTML Panel, Displayed on the left of the page.

Tip: You can change the position of the Edit HTML panel by clicking on the Position icon (right next to the Edit HTML tab on the above screenshot).

To change the CSS styles of the page, use the CSS > Edit CSS option, which will allow you to edit the styles used on the web page.

2) Measure things quickly with the Ruler Tool.

Raise your hand if you’ve ever print-screen’ed, and then copy-&-paste’d the screenshot onto Photoshop just to determine dimensions of certain page objects (like the width of an image) with the selection tool. *Raises hand in shame*

With the Ruler Tool (enable it via Miscellaneous > Display Ruler Tool), you can speedily size-up objects inside the web browser. It’s a great tool in conjunction with outline options such as Information > Display Div Order option or Information > Display Block Size option, allowing you to detect the amount of padding and margin between elements.

Screenshot of the Mozilla Firefox Web Developer extension Ruler Tool.

3) See how web pages look on a non-traditional web browser.

Nowadays, tons of people have mobile devices that lets them view web pages in non-traditional ways. Determine whether your pages render correctly (or close enough) on portable device screens by using the Miscellaneous > Small Screen Rendering option. This saves you from going out and purchasing a Blackberry or a Trio with an internet dataplan just for cross-browser checking.

How the Gamespot website looks on normal browsers:

A screenshot of Gamespot.com viewed through Mozilla Firefox web browser.

What it will look like on a Small Screen Rendering device…

A screenshot of Gamespot.com rendered in a Small Screen Rendering Device as simulated by Mozilla Firefox Web Developer extension.

4) Find out how optimized your page is.

Use the Tools > View Speed Report option to automatically send your page to WebSiteOptimization.com, a site that provides a plethora of information about your web page load times like how quickly your page loads and how many HTTP connections are being used among a ton of other things.

There are built-in tools in Adobe Dreamweaver and Flash (if you even have access to them) that simulates download speeds, but nothing beats a free, comprehensive and actual live speed report.

Screenshot of the result of Six Revision's front page speed report from Web Optimizer

5) Populate web form fields instantly.

Don’t you hate it when you have to fill in your custom-built web form for the nth time because you’re testing it? You can quit tabbing and entering junk information on your form fields and switch to using the Form > Populate Form Fields option in the Web Developer extension.

In the example below, you can see that it populates most web forms somewhat intelligently – It was able to guess the email field — but missed the phone number field.

Screenshot of eBay's registration form automatically filled about using the Forms - Populate Form Fields option of Mozilla Firefox Web Developer extension.

6) Find all the CSS styles that affect an element.

For most fairly-proficient CSS developers, it’s quite easy to find the exact selectors that style an element’s properties - fyi: #selector { property: value; }. This is especially true when you’re the original author and/or the styles are contained in one stylesheet.

But what if you were working on someone else’s project… and the project in question has 1,000+ lines of pure CSS goodness, split into several external stylesheets (because Bob a.k.a. “Mr. Modularity” likes to keep things “simple“)? Another scenario you might encounter is being tasked to theme a content management system like Drupal or Wordpress and you’re not quite sure where all the external stylesheets are.

For example, the Yahoo! home page has over 2,400 lines of CSS, spread over several external stylesheets and inline styles (Bob, you built this page didn’t you?).

Screenshot of Yahoo! front page with CSS - View Style Information of Mozilla Firefox Web Developer extension being used.

If you’re tasked with revising this page, you have two choices: (1) look through, understand, and hunt down the styles you need or (2) decide that you’re smarter (and lazier) than that and so you use the CSS > View Style Information option of the Web Developer extension. With this option enabled, clicking on a page element opens up the Style Information panel which displays all the styles that affect the element.

7) View JavaScript and CSS source code in a jiffy.

One of the ways I troubleshoot rendering issues is by looking at how other web pages do it. JavaScript and CSS are often divided into several files — who wants to look through all of them?

Using the Information > View JavaScript and the CSS > View CSS options instantly displays all the JavaScript and CSS in a new browser tab. This has the side benefit of being able to aggregate all the CSS styles or JavaScript in one web page allowing you to use the Find tool of the Mozilla Firefox browser (keyboard shortcut: ctrl + f for PC users).

8) See how web pages are layered.

It’s often very helpful to determine which page div’s and objects are on a higher plane. Using the Information > View Topographic information gives you a visual representation of the depths of the page elements — darker shades are lower than lighter shades of gray.

Original web design…

Screenshot of before using View Topography Information.

Using the Topographic Information option renders the page to this:

Screenshot of a webpage with Information - View Topographic Information enabled.

9) See if your web page looks OK in different screen sizes.

I use a monitor size between 19 – 22 inches (wide screen). This can be problematic because many of our visitors use smaller monitors. Short of switching to a smaller LCD screen to simulate the user experience, I just use the Resize > Resize window option. It helps test whether my fluid layout works well in smaller windows (sometimes you forget to set min-widths for div elements and it jacks up the layout in smaller screen sizes), or if your fixed-width layout displays important content without user’s having to scroll.

Be sure to enable the Resize > Display Window Size in Title option to help you determine the exact dimensions, and also for documentation purposes when you’re taking screenshots of your webpages.

Screen shot of drupal.org with the width of the page set to 800 pixels.

So there we are, nine ways you can employ the Mozilla Firefox Web Developer extension to better your web development experience. I don’t claim to be an expert, but I certainly know enough about the Web Developer extension to improve my web-building speed.

Do you have other tips and strategies on how to further utilize the Web Developer extension? What are the ways you use Web Developer extension in your job? Share them here.

Related links: