Re: How do we get there from here?

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'? 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