Re: How do we get there from here?


Tom deL wrote:
> Hi Dawn,
>
> Sorry in advance for top posting this but I have only one question and
> didn't want it to be buried:
>
> Can you explain exactly the difference between 'PHP etc with AJAX' and
> 'AJAX approach'?

I am (at least starting by) using php and ajax, but not the php
approach with ajax. The difference is between using the PHP/ASP/JSP
"approach" and incorporating AJAX into it or using the AJAX approach
with PHP, ASP, JSP or whatever for server-side logic.

In the first case, where you use the PHP approach, you would have your
html pages inside PHP documents. In the AJAX approach, you have your
(X)HTML separate and you do asynch call-backs from the javascript
linked to the page back to the server, which could be a php script.
That ships back an xml document (which might have snippets of xhtml
code in it, but is not an entire page) to the JavaScript.

gotta run, so didn't proofread, but does that answer it? --dawn

> Seems you prefer the latter. Why?
>
> TIA,
> -Tom
>
> dawn wrote:
> > michael@xxxxxxxxxx wrote:
> >
> > > So it all comes down to HTML & Javascript still?
> >
> > 'fraid so. Once I understood why that was, I decided to stop
> > resisting. Here's my take on it.
> >
> >
> > The JSP, ASP, PHP, etc Approach
> > I looked at LAMP (linux-apache-mysql-php), ruby on rails,
> > java/jsp/struts, and java server faces in my first round. I did
> > hands-on with all but ruby, doing the basics in each to feel like I
> > "got it" without actually learning more php than required, for example.
> >
> > Each of these used the same philosophy of not only hosting any
> > source/byte/object code on the server, but the run-time environment for
> > each of them too. The user visits a site and a request goes to the
> > server which then interprets the php (or whatever) and pushes html to
> > the client. The client then gets/posts data based on a client-side
> > event (e.g. user clicks submit button) and all logic to validate and
> > process this event is handled again, running on the server, with the
> > php code, pushing back another html document. These must always be
> > complete documents. This seems like a great environment for the
> > developer -- everything is coded and run on the web server, pushing
> > stuff to the browser and making requests of the database.
> >
> > PHP etc with AJAX
> > Since each of these is now adding AJAX support, they are adding what is
> > required to run something on the server (e.g. php) that then pushes
> > javascript, along with xhtml to the client, which then executes the
> > javascript on the client doing the asynch call to the server (e.g. php)
> > to then pull the response back in. This is almost the worst of all
> > worlds from my perspective and I would only entertain it if I had a
> > huge asset of such code already. The casserole of php, javascript,
> > xhtml, and css often jumbled together in a single page doesn't taste
> > right to me at all. (Not to mention that they often also include SQL
> > calls).
> >
> > Browser *User Exits*
> > I don't know how widely people know the term "user exits" but everyone
> > knows the concept -- an application (web browser in this case) is going
> > to run and developers have various points, such as before loading a
> > page, where they can put their own code that will blend with the
> > application. That is where JavaScript comes in. You can write user
> > exits for various user events, such as mouseover or clicking anywhere.
> > Once you see that javascript is the language of the web browser and we
> > are not getting anything else anytime soon (nothing on the horizon even
> > when I put on my high power binoculars) you can see that resistance to
> > javascript is futile.
> >
> > Why No Other Language?
> > It might be easy enough for a single vendor to supply another language
> > in the future for user exits, but I don't see much chance of another
> > standard soon that the browser vendors sort-of attempt to follow. The
> > JavaScript standard is handled by ECMA and officially called
> > ECMAScript. Microsoft, Mozilla, Safari, Opera all care what is in that
> > standard. Some IDEs will generate JavaScript from other specifications
> > so that not every developer will feel a need to learn the language, but
> > then you have to debug it anyway, so I'm biting the bullet and am
> > going to learn it instead.
> >
> > What you can do with JavaScript that you cannot do otherwise -- lots!
> > See http://www.brainjar.com/dhtml/windows/demo.html
> > I have a ton of other URLS, but this one helps explain why AJAX would
> > gain in popularity due to its use of JavaScript along with the asynch
> > server calls.
> >
> > AJAX approach
> > With AJAX, the user requests a page which then goes to the server just
> > like the old days before asp/php/jsp. The html includes scripts and
> > style*** information or, better yet, links to script files and
> > style*** files. The html indicates where there is additional
> > javascript code to go with any event. At those points in the user
> > interaction, the javascript executes and ships asynch requests to the
> > server as needed. The server returns xml, such as fragments of html,
> > that the javascript listens for without holding up the user and
> > incorporates the responses back into the page.
> >
> > An example of how the asynchronous server communication works for the
> > user, try not to get addicted like I am to
> > http://weboggle.shackworks.com
> >
> > Instead of calling these BUIs, I often see them called RIAs -- Rich
> > Internet Applications where a single web page is turned into a full
> > software application.
> >
> > Sorry for the length, but hope this helps. --dawn

.

Quantcast