Know about php?

[Pangloss]

Isn't CGI, equivalant to ASP, and pHp??

 

Albert

 

Yes, more or less. CGI/Perl is the "old and busted" approach to serving full HTML pages (as opposed to just updating the data to a standing XML page ala AJAX), and it has certain limitations (though it still has its followers), the most common complaints revolving around the way it spawns processes for each script (it's not managed). The "new hotness" approaches to full-HTML delivery are discussed above as PHP and ASP/ASP.NET.

[Pangloss]

AJAX runs on the client's computer and can't run on the server. It only delivers information TO the server and displays the response without having to reload the page. There is not more to it.

 

Maybe you should read the article yourself first? It's explained in the paragraph "Compared to traditional web applications".

 

Sure, but that is irrelevant. AJAX is no replacement for PHP or whatever, which is what this discussion initiated. And that you can use an idea and apply it on a different platform is obvious, it's done everywhere in every field of the economy.

 

You might want to consider using some more paragraphs and punctuation to ease readability.

 

Anyways, you just restated what has already been said. And using acronyms and expressions which are obviously unknown to the other readers here has no point besides showing off, which is why I tried to keep it as simple as possible.

 

 

(Just as a side note, this is an academic discussion, not a debate. I'm not trying to evangelize AJAX, I'm trying to learn and to help others learn. So I'd appreciate it if you'd watch your tone. Thanks.)

 

 

Again I'm not an expert on AJAX, but so far as I can tell, AJAX does appear (to me anyway) to have the potential to "replace" PHP. I'm sure we would all agree that, from the user's perspective, it makes no difference what the delivery method is -- what matters is that the content is delivered. So far as I've seen (in my limited experience thus far), there doesn't appear to be anything you can do in PHP that you can't do in AJAX. I imagine that each approach has its advantages and disadvantages, but to me this seems like a question of semantics and methodologies, not end results.

 

So could give us some real-world examples, Icheb? What I'm looking for are some specific things that you can do in PHP that aren't possible in AJAX. Thanks.

[Icheb]

AJAX is a means to access the server and to display the results of a user's input without reloading the page. It can't replace anything that runs on the server. It would be like saying the Internet Explorer can replace the internet. If you have specific questions about this, please state them. But I am not going to repeat myself over and over again.

[Dave]

So could give us some real-world examples, Icheb? What I'm looking for are some specific things that you can do in PHP that aren't possible in AJAX. Thanks.

 

I think that's a pretty specific question, myself.

 

Icheb, none of us is on some kind of crusade to rid the world of PHP and introduce client-side scripting everywhere. A lot of people just want to learn, and your answers are being rather abrupt at the moment I'd much rather not have this thread go the way that others have been going at the moment.

[Pangloss]

So you can't give me any specific examples of a web application that can be constructed with PHP but not AJAX?

 

The reason why I say it's a question of semantics and methodologies can be expressed with this simple example: Let's say you have an MySQL database, and you want to deliver information in that database to users. You construct a set of XML pages on the server, and write a set of JavaScript scripts to serve them.

 

In this example, the same end result has been achieved as could be achieved by, for example, a full-blown PHP or ASP.NET application. But what do you need PHP for in this scenario? What does it give you that you do not get with the AJAX (XML+JS) approach?

 

What scenario involving delivery of information to end users requires PHP and cannot be handled by an XML/JavaScript approach?

[Pangloss]

Darnit, Dave! Dont interrupt me while I am adjusting my tin foil hat! ;-)

[Aeternus]

Pangloss, I think the problem is that JavaScript is used in the context of AJAX as a client side scripting tool (ie browser etc) rather than server side and static XML pages server side really wouldnt do much, there would have to be something server side to generate these XML pages or to serve them up (ie PHP, Perl, or if that link i pasted is accurate, server side JavaScript) or otherwise the content wouldnt be dynamic (ie accessing database etc, a simple XML page won't access the database for you unless you set some other script up server side to do this).

 

While JavaScript apparently can be used as a server side script (although i havent seen it and i dont think its used very often), that isnt the case with AJAX, AJAX simply refers to the client side javascript interacting with something serving up XML on the server side (whether that something be an XML document or cgi script serving up XML content), which is where saying AJAX could replace PHP or Perl as a solution doesnt seem to make sense as AJAX refers to the client side aspect and the method of communication (XML content) with the server side aspects.

 

PS- I'm no expert and you may well find evidence to the contrary but this is what I have read, understand from what I've encountered.

[Pangloss]

Pangloss' date=' I think the problem is that JavaScript is used in the context of AJAX as a client side scripting tool (ie browser etc) rather than server side and static XML pages server side really wouldnt do much, there would have to be something server side to generate these XML pages or to serve them up (ie PHP, Perl, or if that link i pasted is accurate, server side JavaScript) or otherwise the content wouldnt be dynamic (ie accessing database etc, a simple XML page won't access the database for you unless you set some other script up server side to do this).

[/quote']

 

I appreciate the feedback, but this is really not the case. The XML pages in AJAX are not static. Data is accessed from a database or other data entity via the HTMLHttpRequest object.

 

(Icheb agreed with this point, but he feels that the AJAX approach cannot replace PHP for some other, unspecified, reasons.)

 

 

 

While JavaScript apparently can be used as a server side script (although i havent seen it and i dont think its used very often), that isnt the case with AJAX, AJAX simply refers to the client side javascript interacting with something serving up XML on the server side (whether that something be an XML document or cgi script serving up XML content), which is where saying AJAX could replace PHP or Perl as a solution doesnt seem to make sense as AJAX refers to the client side aspect and the method of communication (XML content) with the server side aspects.

 

PS- I'm no expert and you may well find evidence to the contrary but this is what I have read, understand from what I've encountered.

 

I don't think that's correct -- I don't think there *has* to be a server-side application running at all (aside from the HTTP daemon itself). I don't think there's any PHP or ASP.NET or even CGI going on behing Google Maps, for example. I think it's just serving up dynamic XML updates upon user request. It just has an active application "feel" to it.

 

 

 

Just to explore this a bit further, I'm not saying you never need server-side technology. I'm asking why you couldn't replace PHP with AJAX. There's a very subtle distinction here.

 

Obviously you need some sort of server-side application if any sort of processing is required on the server when a user is not around. This is not generally the case even with dynamic web sites. Google Maps, for example, is simply letting users pull data from a database. If you needed to do something like shift your inventory from a warehouse to a distribution center at a pre-specified time, or anything else you want done without user interaction, then you would need some sort of server-side executable running.

 

But you wouldn't build inventory management software with PHP. In fact, web service is typically an afterthought to an existing company-wide, LAN/WAN-based, DBMS-centric system with a heavy front end installed on people's desktops. You're not going to mimic that in PHP, you're just going to serve data from it.

 

The only thing I've been able to think of that might answer my question to Icheb would be something like portal software, such as this message board, or Nuke, or in the ASP world stuff like DotNetNuke, Community Server, blog software, etc. Stuff that requires server-side processing but it's primary function is to serve web pages to users.

 

But even here there's a rub -- I don't know that you couldn't simulate/replace all of the functionality of a portal program with a clever combination of XML/JS and a good database with cleverly written stored procedures. DBMSs (even the freebie MySQL) have a pretty rich and powerful set of features, and are more than capable of managing permissions, archiving data, and performing other automated functions. And your front-end XML/JS pages can easily simulate the appearance of portal software.

 

In fact, we typically bypass a lot of those built-in DBMS functions when we build web applications these days anyway, because there's no point in having two levels of functionality. For example, a typical web app will require the user to log in uniquely, but *the app itself* will always log into the DBMS the same way -- with a pre-specified username and password that's actually stored in the application code! That's the sort of thing that really makes you wonder -- why have we reinvented the wheel? But that's how it's done today, in every web application from ScienceForums to Amazon.com.

 

 

So we're back to square one. So far as I can tell thus far, there doesn't appear to be anything you can do in PHP that you can't (in theory) do in AJAX. Which is why I called this a matter of semantics and methodologies, not capabilities. (But I'm all ears here.)

[Aeternus]

I agree that AJAX would work fine accessing and displaying/processing static content, but i disagree with you on the direct accessing of the database and I don't think you could illicit requests to the database using XMLHttpRequest (rather than HTMLHttpRequest which as far as im aware is central to AJAX (never even seen it)).

 

Not sure if you mean that there are some databases that are happy to serve up XML data and recieve queries (ie insert/update queries) via Http requests but then i would say that that database was the server side processing rather than simply AJAX.

 

XMLHttpRequest is simply a function that sends a Http Request to the webserver for an XML file/ Something that requests the XML content and then the XML is processed by the function into a nice simple DOM object that can be used easily to parse the XML and use its contents, as far as i am aware there isnt anything magic about it that would allow it to manipulate databases or change anything server side. Therefore doing something dynamic that requires something to be stored server side (ie in a game, a messageboard (as you said), banking, almost any sort of portal etc) wouldnt work with a purely AJAX approach.

 

Maybe I'm misunderstanding what your saying, maybe I'm misunderstanding the AJAX approach or something involved. These are just my 2 cents.

 

XMLHttpRequest Info

 

PS - Maybe we should move the AJAX specific conversation over to another thread or something ?

[Pangloss]

Hm, yes, I see your point. This article in particular seems to support what you're saying. This picture seems to be particularly revealing:

 

 

That certainly seems to point toward the XML files not doing the job of actually pulling the data from the back-end database program (ala MySQL). Yes, I think you're right, and Icheb about much of this as well, and I was wrong.

 

If this is true then it does still represent a major change in the way web applications can be developed (I disagree with Icheb on that, but I respect his opinion on it), and vastly reduces the need for "heavy" apps like PHP and ASP.NET delivering full-blown web pages to the end user. But you're right, it's still got to have some sort of piece at the back end doing the database work. PHP, ASP.NET, CGI, whatever. Maybe something else entirely ("legacy" apps, as indicated in the image). In fact it seems to kinda open a few doors there, doesn't it?

 

Thanks for sticking in there with me on this.

 

I'm going to do some more poking around with AJAX and I may post a new thread on it for more discussion later.

[Aeternus]

If this is true then it does still represent a major change in the way web applications can be developed (I disagree with Icheb on that, but I respect his opinion on it), and vastly reduces the need for "heavy" apps like PHP and ASP.NET delivering full-blown web pages to the end user. But you're right, it's still got to have some sort of piece at the back end doing the database work. PHP, ASP.NET, CGI, whatever. Maybe something else entirely ("legacy" apps, as indicated in the image). In fact it seems to kinda open a few doors there, doesn't it?

 

Agreed Although techniques similar to AJAX (like using hidden Iframes and requesting script responses via that etc) have been around for a while, the fact that AJAX offers a clear and standardised way of doing it (Javascript's XMLHttpRequest() + XML feeds etc) and the fact that it is gaining so much popularity (due to its obvious advantages) recently make it an idea/technique to be counted

[Icheb]

That certainly seems to point toward the XML files not[/i'] doing the job of actually pulling the data from the back-end database program (ala MySQL).

Because they can't do that. XML is just the output, it's not a programming language. You need PHP to output the XML.

 

If this is true then it does still represent a major change in the way web applications can be developed (I disagree with Icheb on that, but I respect his opinion on it), and vastly reduces the need for "heavy" apps like PHP and ASP.NET delivering full-blown web pages to the end user.

It's not my opinion. It's how it's done. I am in this field for four years now, so I know how this works.

It doesn't reduce that need for heavy apps, because that's not what AJAX does.

 

AJAX does only the following:

Send user input to the server and display the output of that action without having to refresh the page. Nothing else! It does not act on the server, it doesn't access the database, nothing! It completely sits on the user's pc and gives the user a streamlined web interface. That's what I am trying to tell you for countless posts now.

 

I quote myself:

AJAX runs on the client's computer and can't run on the server. It only delivers information TO the server and displays the response without having to reload the page. There is not more to it.

Maybe you should read the article yourself first? It's explained in the paragraph "Compared to traditional web applications".

So please' date=' read that article yourself first.

 

If you don't understand the technology, please learn it first before telling me I'm wrong.

[/size']

[YT2095]

Icheb, it would seem that you`re taking all of this a little to "Personaly" for some reason?

 

and some parts of it in the wrong way that it was intended, Lighten up a bit!, we`re NOT your enemies, it`s simple a discussion

[Aeternus]

Icheb, he didnt say in that post that it did anything server side and he even agreed that XML didnt do anything server side (which obviously it couldn't as XML is just a markup language like HTML or similar which doesnt actually do any processing).

 

All Pangloss said was that it was a way that could change the way web applications are handled and reduce the need for heavy server side applications which is perfectly true in that it means whole pages dont have to be returned (with the whole POST form, get returned a whole new page, POST something else get a completely different page etc) (saving bandwidth) and often as Pangloss mentioned in his previous posts, alot of content is static but just requires processing to be displayed correctly depending on the user's input which is fine for AJAX.

 

While you may not agree that this is a radically new way of doing things (and i agree with you, as similar things have been done for a long time, as well as the fact that its simply an almalgamation of 2 existing technologies and not a technology in of itself, as well as the fact that effective caching technique and good design can offer similar benefits), Pangloss is entitled to his opinion there.

 

I respect that you have experience and may know alot about the subject and I'm sure Pangloss does but I think sometimes it would be nice if you would at least admit that perhaps you are misunderstanding what someone means or says. You seem to be taking this a little bit personally. Sorry if i have caused any offense and obviously feel free to comment on what i have said.