Jump to content
Larry Ullman's Book Forums
Sign in to follow this  
markifornia

Chapter 3: Browsing Using Ajax, Page 31

Recommended Posts


ajax.open('get', dept_results_ajax.php?did=' + encodeURIComponent(did)));

 

My question is actually a simple one. To create an ajax driven web application are two similar php files necessary? ie dept_results.php (non ajax version) and dept_results_ajax.php (ajax version)? Can there be one file that can also be the fallback?

 

I may be getting ahead of myself, as I am only on chapter 3. I am just trying to see how others have built their ajax web applications.

 

Thanks,

Mark

Share this post


Link to post
Share on other sites

You could write it all in one script if you wanted, it'd just take more complicated logic. But the one script (dept_results.php) IS a fallback for the other.

  • Upvote 1

Share this post


Link to post
Share on other sites

Larry, I was thinking about this myself recently, as I always go the traditional approach of writing two similar (and sometimes long) scripts.

However, after thinking about it quite a bit, because so much of the logic between the two versions is the same, I was wondering if there's an efficient way to reuse a lot of the code. (Of course, the code can be copied and pasted into another file with the necessary changes made, but then essentially two versions of the code have to be maintained.)

 

For example, let's say we want to have a validation script that we want to run both with Ajax and without Ajax.

Would a practical solution be to perform all the validation in one script, and then include that script in two other different files: one file (the non-Ajax one), which would simply redirect the user to another page after the validation script was included, and the other file (the Ajax one), which would simply echo the necessary information back to the JS in the script that made the request after the same validation script was included?

This would actually result in three scripts instead of two, but it actually seems more efficient and eliminates the need to maintain two versions of essentially the same code.

 

When you think about it, quite often, it seems like the only difference between the two versions of a PHP script is the way information is output for Ajax vs. non-Ajax. As such, making everything the same except for the output seems like a logical thing to do.

What are your thoughts on this, Larry?

Share this post


Link to post
Share on other sites

I understand what you mean about the logic being the same in both the Ajax and non-AJax versions, but the output is so different that I still keep them separate. With your validation example, look at the output: the non-Ajax has to store the errors in an array and then use PHP code to put those errors in the right place. Conversely, the Ajax version has to return XML or JSON. Those are night and day differences, and while the validation itself is the same in both cases, only the tests are the same: what should be done--add to an array or to XML/JSON--is quite different.

 

The same can be said for a script that does a SELECT and displays/sends the results.

 

In my opinion, the hardest part is the output, so you should take whatever steps you can to make that easier. Conversely, the easiest part is the common elements--validation or SELECT or..., so it's not likely to be a problem if that's repeated. Just my opinion, but I've not seen a combination script discussed as a better alternative anywhere.

  • Upvote 2

Share this post


Link to post
Share on other sites

You've both pointed out some advanced concepts just beyond me in my learning process, but I see both ways working. I've built some forms just using PHP and Javascript where I'll have the form dynamically load the form (including javascript validation routines), and then have a noscript version of the form handled by PHP (the fallback, with validations). So here, I have done the same thing - two versions - let me tell you though, this method has worked successfully against spam bots. My forms are completely CAPTCHA free. So I drew a parallel to my approach.

 

But here I am learning how to build ajax applications. I'm not looking at the task lazily but just imagine a large web application. My first thought is that if I have many pages, I would have to build an ajax and a non ajax version for each one. It does make sense to do so, it is not like every page should be dependent on ajax right. Ajax is also useful in updating just a specific part of the page (such as a poll). I have not built a large ajax web application, so I may have no say in this at this point.

 

As Larry confirmed, two versions is the best way to go about it as I drew that parallel with my experience with building contact forms. Assuming ajax driven forms aren't used heavily throughout the web application, which I think is often true than not (just a guess).

 

I guess when I thought about this approach, I started thinking okay - I have 100 pages, now I have to build 100 ajax versions and 100 non ajax versions. I was thinking overkill. Not the case.

 

Thanks for the input

Share this post


Link to post
Share on other sites

I understand what you mean by the task sounding very daunting.

 

Luckily, there is a lot of overlap between the Ajax and non-Ajax versions. Almost always, the logic is the same, but the input and output methods differ.

 

Also, I imagine that most of those 100 pages you have don't involve forms and other complex structures. In most cases, the only difference between the two should be whether you use Ajax or not to load the page.

 

Which reminds me of another point that Larry makes in his PHP advanced book: By making your site as DB-driven as possible, you can minimize the number of scripts/pages you have to write, which will greatly ease the transition to Ajax.

 

As a final point, there's nothing wrong with using JS to validate every form on your site so long as you always have PHP performing the final validation.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×