Jump to content



Photo

Converting An Existing Php/Mysql Web Site To Ajax


  • Please log in to reply
7 replies to this topic

#1 ramasaig

ramasaig

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 4 April 2012 - 6:18 AM

I run a web site http://www.holidaymull.co.uk that lists tourist accommodation and attractions. It's built using PHP and MySQL, and has an index.php control script. Every search (or other change) made by visitors calls the control script, and of course the page is refreshed (or a new page written) every time. See http://www.holidaymu...n/B&B/SouthWest for a typical search results page. (These links are to the NON-Ajax site, there's no public Ajax version yet)

Most of the search results are displayed within the same template, and it would seem a natural for converting to Ajax. At least two separate areas of the screen need to be updated: first the results themselves, and second the short-list information (which, when present, shows above the results). The form(s) for users to select options are permanently in the left-hand column, and are just a series of checkboxes. I've attached an onsubmit event handler via JS.

I have tried extracting parts of the control script and calling them via Ajax (togther with the code that actually displays the stuff), but the sections of the control script are so interdependent that although the Ajax part seems to work OK I don't get the results I want (there are always loads of PHP error messages referring to other parts of the control script that I've not included).

The next thing I'm going to try is to create a 'control.php' file from all or most of 'index.php' script, and call that with Ajax (or even call 'index.php' itself, 635 lines of code). My thinking here is that since the non-Ajax version calls the control script every time it can't possibly be wrong to do the same in the Ajax version. Obviously I'll have to avoid having to maintain two versions of the control script. Does that seem a sensible approach, or can you suggest a better way ?

Unfortunately (perhaps) re-designing the site from scratch isn't an option because of time constraints.

Regards,

Tim Dawson
  • 0

#2 Larry

Larry

    Administrator/Writer

  • Administrators
  • 3,537 posts
  • LocationState College, PA (USA)

Posted 4 April 2012 - 7:26 PM

I don't see why you would want to send the Ajax version through the control script. It's a different type of request, use a different, more direct, approach.
  • 0

#3 ramasaig

ramasaig

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 5 April 2012 - 7:58 AM

Hello Larry,

Thanks for your reply. It's not that I WANT to feed the Ajax version through the control script, but I haven't worked out an alternative that will work.
In the pre-Ajax version, almost every visitor click becomes a GET query string, and is fed into the control script which filters it and applies the appropriate action (from simple page request to DB searches and short-list building etc.). Search query strings are parsed into MySQL queries, and the returned results massaged into a PHP array and fed to the Search Results page template for display. (If the visitor starts on the home page this also requires a new page to be loaded).

In the Ajax version I've successfully applied an 'onsubmit' event handler to the Search Box which produces the same query string (via JS) according to the checkbox selection. This too needs to be converted into a MySQL query and put through the same process as above. Hence the apparently simple option of feeding it into the control script.

I will look into the possibility of simplifying the control script so that it still includes the filters, but the subsequent actions are in 'included' files, which can also be called directly by Ajax. I'm keeping in mind that it's still got to work with JS turned off.

Thanks for your help.
  • 0

#4 HartleySan

HartleySan

    Advanced Member

  • Members
  • PipPipPip
  • 2,692 posts
  • LocationColumbus, OH USA

Posted 5 April 2012 - 11:34 PM

If your non-Ajax version works fine, which it seems to, then I don't think you need to worry about the Ajax layer messing up the non-Ajax layer.

With that said, like Larry, I am somewhat confused about why the 600+-line control file (with additional include files) is necessary in the first place. Certainly, I understand the need to filter user input as much as possible, but given the site design, it seems like overkill (although this is based on just my initial impression).

I suppose the quickest solution would be to make a second copy of the control script for the Ajax version, and then edit that file to make it do what you want it to do dynamically.

Just to offer some general guidance, here's the flow I'm thinking of for a given page on your site:

document.forms[0].onsubmit = function () {

// Do a quick check of all the input to make sure that the basic requirements are met.
// Don't submit anything unless they are.

// If the request is simply a get request, create the URL string.

// Set up (instantiate) an Ajax object, if it isn't already.

ajax.open('get', 'handleRequest.php?' + string-of-parameters, true);

ajax.onreadystatechange = handleAjaxResponse;

ajax.send(null);

return false; // This supresses the normal submitting of the form.

};

function handleAjaxResponse() {

if ((ajax.readyState === 4) && (ajax.status === 200)) {

// Receive the data processed by the PHP page via ajax.responseText or ajax.responseXML.

// Parse the returned data as necessary.

// Use document.getElementById, etc. to locate the element you want place the data in,
// and then use the innerHTML property to actually place the information
// in the right location on the screen.

}

}



handleRequest.php

<?php

// Assign all the parameters to PHP variables if need be.

// Run each of the variables through the necessary filters. I highly recommend using PHP's
// built in filter functions for this as much as possible.

// Note any problems/input errors, and send that info back to the JS script.

// If there aren't any errors, make the DB request and return the proper results.

?>

That's basically it. Granted, I know some of those steps require some code, but all the same, I can't imagine it requiring the whole 600-line control file.

Also, you might consider making separate (smaller) control files, depending on the task. For example, one control file for searches, one for handling booking requests, etc. That might make the file considerably smaller and more manageable.

Anyway, just my suggestions. Take 'em or leave 'em. As a final note, I looked at your site in IE6 ('cause I have to use it at work), and it has some display issues. If you're concerned about IE6 users, you might want to fix those issues.

Also, sorry about the sloppiness of my pseudo code above, but this forum doesn't not support any formatting tools in IE6 (much to my chagrin).
  • 1

#5 ramasaig

ramasaig

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 6 April 2012 - 8:38 AM

Hello HartleySan,

Thank you for your response, and for taking the time to look at the non-Ajax site.

The good news is that (just before reading your response) I have got the basic Ajax function working (So far I can update an accommodation search), showing the new listings. At the moment the Search Results summary (above the listings) isn't updating. I think this may require a second Ajax object, and I'll be looking into that next.

You very properly question the need for such a long control script. The script handles almost everything the site does (there are few direct links between pages). This includes searches, several alternative DB calls (saving queries etc), visitor short-listing of search results, selection of template pages, and other stuff. I'm sure there's room for improvement, but essentially all that code has to be somewhere. If it's not in the control script it'll need to be in some included files.

What the control script does is to filter any query string (or POST data) sent to 'index.php'. This might be a search as in '?ac[3]=BB&loc[2]=CT&save=accn&accns=Search' or a click-through from a listing such as 'locn=www.ardnacross.com/&id=2179' or a request for another page '?pages=eaglewatch'. POST data includes adding or removing from short-list, viewing and editing shortlist etc.

However, all that is a digression from the original intention to ask about the best way to implement Ajax on this site. If I made another copy of the control script for Ajax purposes I'd quite possibly have to maintain two similar but different branches of code, which I'm reluctant to do. So it's still my intention to make the control script more modular (i.e using included snippets). In Ajax, because I'll know the nature of the query or POST data, I hope I need only call the appropriate snippet, not the entire script. (And who knows, if I apply that to the Ajax I may also be able to apply it to the non-Ajax. We'll see).

I accept your comments about display in IE6. I've taken the possibly controversial decision not to continue supporting it. Visitors using IE6 are only 1.04% of the total. An additional reason is that I no longer have any means of viewing in IE6 myself (I could, of course, if I set up a virtual machine).

Thank you for your help (and the encouragement that gives).

Regards,

Tim Dawson
  • 0

#6 HartleySan

HartleySan

    Advanced Member

  • Members
  • PipPipPip
  • 2,692 posts
  • LocationColumbus, OH USA

Posted 6 April 2012 - 12:24 PM

I completely understand your desire to not worry about IE6. That's totally cool. Just wanted to mentioned it in case.

Anyway, for your search results page that requires two areas to be updated, creating two Ajax objects is a possibility. That's actually what Facebook does, and is partially why their site loads so fast; they create a new Ajax object for each part of the screen, and send them all out at once, and then load stuff as the various responses come back.

However, that is probably not necessary for your page. In general with Ajax, it's usually best to minimize the load on the PHP script and server as much as possible. Instead, you want to have JS handle as much as possible on the client end. This ends up being faster and more efficient for all parties included in almost all cases.

As such, when you send the request from the JS to the PHP script, I recommend sending all the variables you need to get the necessary data for both parts of the page, make the two DB calls from the same script, organize the data returned from the DB calls in as lean a fashion as possible, place some sort of unique delimiter between the two parts of data, and then echo it back to the JS like that.

After JS receives the data, you can easily split it on the delimiter, and then do whatever you have to do from there.

Well, that's what I'd do at least. Lemme know what you decide to do. Thanks.
  • 1

#7 ramasaig

ramasaig

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 13 April 2012 - 5:53 PM

Thanks for your comments. I took a few days off over Easter, but I'm back at this now (though not full time).

I have managed to split up my control script into several modules. The 'index.php' file now consists of a 'cascade' of conditionals (mostly) applied to the $_GET query string, but in some cases to $_POST. Appropriate modules are called as required. The first task was to get it all working exactly as before (without Ajax), which I think I've achieved. The main search function is working well in Ajax, it's the smaller bits which are proving resistant at the moment.

I should soon be in a position to upload a version to my test site (with partial Ajax), which I hope will make further discussion easier and more task oriented rather than generalisations.
  • 0

#8 HartleySan

HartleySan

    Advanced Member

  • Members
  • PipPipPip
  • 2,692 posts
  • LocationColumbus, OH USA

Posted 13 April 2012 - 11:02 PM

Sounds good, and glad you're making the effort on your own. As frustrating as it can be at first, that's ultimately how you learn.

And certainly, don't be afraid to ask more questions as they come up.

Good luck.
  • 0