I'm anxious to know what qualifies as an ajax '*application*' in your book....
I would define an application as a system with input, process and output designed to solve a problem that is less than elementary usually involving at least two user screens and more than one database table.
You may need to be solid in all that to make a large production application but there's no reason you can't pound out something from Ajax tutorials... Most of what was mentioned that you "need to know" you don't "need to know" to make a simple Ajax "application".
OK yes I believe I was defining the skills required for a professional AJAX application which I admit may be out of place in this case.
Yes, you need to know some PHP (or other server side language, but really not necessarily, could just be a flat file that XMLHttpRequest gets), HTML, and Javascript.
For the most simple of applications you could, yes, get by with very little knowledge of PHP but the second you want to start creating an AJAX application that peforms a couple of different actions, has states and conditions you really should have a degree of familiarity with PHP.
You only need to know DOM well if you're using Ajax to process XML output, which isn't necessary. .innerHTML and the Ajax code is about all that's required.
I dispute this. You need to use the DOM in some form or another to get or put any data into an existing HTML document. Understanding the basics of the DOM such as the structure of nodes and the properties each node is likely to have will make these tasks possible without it you will end up copying and pasting code code of forums.
You don't necessarily need a database
True. But we use databases because they make storage and retreival of structured information easier. It is not likely that without one you would require much greater knowledge of XML, DOM, and PHP in order to store and retreve structured information. I know which I think is easiest. I am again of course referring to a level of varied user interactivity that would be seen in an AJAX application. In the most basic of basic AJAX usage this point may not be true.
You don't need to know any of those XML technologies although you can. PHP can output either, so it can just output HTML or just plain text. Use responseText instead of responseXML... Although XML has it's value, it's not needed here and really just adds overhead for something simple.
Absolutely. I'm an avocate of this fact. I've put off learning XML and XML based technologies. But once again even I have to admit that building an AJAX application is much easier for those that know and understand XML well this fact become more pronounced as an AJAX application grows in size.
I could be really picky and say that you need to use XML in order to be writing AJAX.
No OOP needed, but we won't start that debate again. PHP really plays a lesser roll in most Ajax applications anyways because it's only serving out the relevant portions after it serves out the application initially. Needs to be leaner and meaner to handle increased requests that are inherent in Ajax.
Procedural code is better when things are small but if you know OOP and your application is of a resonable size you will benefit from using it. But no you don't *need* OOP in the same way you don't need to write AJAX to make a web application. Also if you are going to provide a AJAX and non-AJAX (for those without JavaScript) functionality for your application you will need to identity areas of code reuse and objects will make this easier. I guess I think of AJAX as while an elitest technology, and the elite should write non-AJAX alternatives with all their AJAX applications and should be worthy of using AJAX.
I don't see why you need a framework to do this. Javascript asks for data just like a browser always has, PHP does its thing and responds back just like it always has but only with relavent data. A Framework might have it's place but probably not here... Use common names between JS and PHP not sure what else you need to synchronize. First word is Asynchronous for a reason : )
Asynchronous in this case is referring to the fact that users no longer need to wait for an entire page to load to get what they want. AJAX still requires the synchronization of client and server because you simply cannot avoid the fact that this is still the HTTP protocol where the server and client must work together to deliever something.
Let me give you an example. Say you have a form where your user will fill in their ZIP/Post Code and first line of their address followed by a selection of checkboxes for different pizzas. With AJAX the Zip/Post Code will be validated on the client as will the address but as we all know these validations must be completed on the server otherwise people will be able to spoof your site. So this is going to require some synchronization between client and server namely the validations will have to be the same. The client and server also have to be synchronized in that they need to be able to understand the responses / requests coming from each other.
I don't think Ajax changes anything about Web Security that doesn't exist in regular applications. Ajax does add to more things JS can do such as embedding Ajax in text areas that would then run on the admin side when they view the entry when an admin was logged in, effectively performing tasks as the admin, likely without them even knowing the browser is even doing anything, but that affects any web system.
You're right AJAX doesn't change web security but I wouldn't bulid a professional web application, AJAX or not, without excercising my present knowledge of web security.
HTML, JS, Server Side, probably Database, sure you can incorporate far more and make more advanced applications, but that doesn't sound like what the poster needs.
Yes you're right. I'm clouded somewhat but my attitude to AJAX and my belief that you should only use it when you know what you are doing but on a small scale this can be wavvered and I wish Red Blaze luck with his AJAXy endevours.