AJAX support?

Discuss features as they are added to the new version. Give us your feedback. Don't post bug reports, feature requests, support questions or suggestions here.
Forum rules
Discuss features as they are added to the new version. Give us your feedback. Don't post bug reports, feature requests, support questions or suggestions here. Feature requests are closed.
SamG
Registered User
Posts: 1241
Joined: Fri Aug 31, 2001 6:35 pm

Re: AJAX support?

Post by SamG »

alcaeus wrote: Um....huh? You say that DHTML has to wait for a full HTTP cycle, but then again you say it doesn't tinker with it? I don't get it :-?
That's correct. DHTML pages work exactly like non-DHTML pages when it comes to HTTP requests on processing. That's not the case with AJAX stuck in between client and server. AJAX tinkers with the normal request cycle, unlike DHTML.
markus_petrux
Registered User
Posts: 376
Joined: Fri Jun 18, 2004 10:58 pm
Location: Girona, Catalunya (Spain)
Contact:

Re: AJAX support?

Post by markus_petrux »

No, no, no. :)

I know AJAX is coming with lots of bells and whistles :P ...so, I created a small MOD to compare code size, speed and complexity of a DHTML based approach versus a AJAX one. :)

Code Size: While the dynpreview MOD I posted here (http://www.phpbb.com/phpBB/viewtopic.php?t=308001" target="_blank) just uses two code snippets, a patch for posting_body.tpl (67 lines of javascript and 20 lines of HTML) and a script to process the request in the server (113 lines of PHP code and comments), wGEric's AJAXed MOD uses also a bit of code. Note the later comes with more features, so it's bigger than mine.

Code Speed: The DHTML thingy I wrote works so every second it checks if the posting textarea has been changed, if so am HTTP request to refresh the preview area is launched through a hidden IFrame. BBCodes et all are parsed on the server. When the onload event of the IFrame fires, the preview area is updated using the innerHTML attribute of the layer. It does not generate a full HTML page within the IFrame, but much less is required for the purpose. For instance, if the user types "[b]Hello world![/b]" in the posting textarea, the IFrame will come with:

Code: Select all

<html><body><div id="dynpreview_php"><b>Hello world!</b></div></body></html>
HTTP requests: Both DHTML and AJAX use HTTP to contact the server, that means both rely on GET/POST/COOKIES to pass parameters, so the script on the server should take into account same security related issues, etc. with both techniques. As per the responses from the server, well the above "Hello world" example shows DHTML does not need the whole HTML page to do its job, not to mention XML could also be used, or it could also be Gzip compressed (probably AJAX can also do this, as it might depend on the script on the server).

Complexity: Well, it depends. ;) ...AJAX is more complex IMHO 'cause it involves more cross-browser issues and new (non-standard) interfaces to do the job. DHTML just uses innerHTML and IFrames (part of the DOM).

My point here is DHTML was here before and no one asked the phpBB developers to add Remote Scripting capabilities to phpBB. Why ask them to use AJAX now, when DHTML was here before based on standards? hmm.... bells and whistles. :P
R. U. Serious
Registered User
Posts: 32
Joined: Mon Feb 11, 2002 2:07 pm
Contact:

Re: AJAX support?

Post by R. U. Serious »

DHTML and AJAX are both marketing terms, they are not standardized so it's futile to discuss the differences. Before the term AJAX was coined the exact same things were going under the label DHTML for years. And people that never liked those Marketing terms were "just" calling all that Javascript and still do.

Also (in response to someone earlier claiming sth. else) XML has very little to with AJAX as implemented by most people. If you have little data, that is not very complex/hierachical most people skip the step of creating xml serverside and traversing that client-side. It just so happens that XMLHttpRequest is the name of the object available to make those HTTP requests.
Das Kölsch zum Handy.
alcaeus
Registered User
Posts: 66
Joined: Sun Oct 10, 2004 3:21 am
Location: Munich (Germany)
Contact:

Re: AJAX support?

Post by alcaeus »

markus_petrux wrote: HTTP requests: Both DHTML and AJAX use HTTP to contact the server, that means both rely on GET/POST/COOKIES to pass parameters, so the script on the server should take into account same security related issues, etc. with both techniques. As per the responses from the server, well the above "Hello world" example shows DHTML does not need the whole HTML page to do its job, not to mention XML could also be used, or it could also be Gzip compressed (probably AJAX can also do this, as it might depend on the script on the server).
AJAX relies on XML, and it could be GZIP-compressed. However, especially when sending small amounts of data (as stated before, normally around 200 KB), GZIP overhead may as well be larger than the actual data ;)
markus_petrux wrote: Complexity: Well, it depends. ;) ...AJAX is more complex IMHO 'cause it involves more cross-browser issues and new (non-standard) interfaces to do the job. DHTML just uses innerHTML and IFrames (part of the DOM).
Cross-browser issues? No. There are only two things I noticed in IE (i heavily tested it in IE) are the following: it does not contain the native XMLHTTPRequest object, but you have to go over the Microsoft.XMLHTTP ActiveX object; and: when using autocompletion, the onchange method of an input field is not called. That's it, my codes worked fine the very first moment I tested them in IE, FF, Opera and Safari :)
markus_petrux wrote: My point here is DHTML was here before and no one asked the phpBB developers to add Remote Scripting capabilities to phpBB. Why ask them to use AJAX now, when DHTML was here before based on standards? hmm.... bells and whistles. :P
No, not bells and whistles. To me, AJAX is more dynamic than DHTML, but I can also be wrong here, so don't beat me :P
I have just started playing around with AJAX a little bit, and I have realized that it's kinda sweet. That's why I asked if it would be in there, and not if they could implement it ;)
R. U. Serious wrote: Also (in response to someone earlier claiming sth. else) XML has very little to with AJAX as implemented by most people. If you have little data, that is not very complex/hierachical most people skip the step of creating xml serverside and traversing that client-side. It just so happens that XMLHttpRequest is the name of the object available to make those HTTP requests.
*coughs* And why is it called "Asynchronous Javascript and XML"? Exactly: because the output is generated as XML data. Everything that doesn't use XML has not the right to be called "AJAX" ;)

Greetz
alcaeus
markus_petrux
Registered User
Posts: 376
Joined: Fri Jun 18, 2004 10:58 pm
Location: Girona, Catalunya (Spain)
Contact:

Re: AJAX support?

Post by markus_petrux »

alcaeus wrote: AJAX relies on XML, and it could be GZIP-compressed.
Ok, this is reasonable, as it happens on a lower layer, transparent to the client side script.
alcaeus wrote: However, especially when sending small amounts of data (as stated before, normally around 200 KB), GZIP overhead may as well be larger than the actual data ;)
200KB? I guess you tried to meant 200 bytes. Even in this case, I believe it would worth. Quoting from the zlib web site:
Maximum Expansion Factor

zlib's compression method, an LZ77 variant called deflation, emits compressed data as a sequence of blocks. Various block types are allowed, one of which is stored blocks—these are simply composed of the raw input data plus a few header bytes. In the worst possible case, where the other block types would expand the data, deflation falls back to stored (uncompressed) blocks. Thus for the default settings used by deflateInit(), compress(), and compress2(), the only expansion is an overhead of five bytes per 16 KB block (about 0.03%), plus a one-time overhead of six bytes for the entire stream. Even if the last or only block is smaller than 16 KB, the overhead is still five bytes. In the absolute worst case of a single-byte input stream, the overhead therefore amounts to 1100% (eleven bytes of overhead, one byte of actual data). For larger stream sizes, the overhead approaches the limiting value of 0.03%.

deflateInit2() includes arguments for windowBits and memLevel that permit settings other than the defaults. These parameters can be used to adjust the memory required for the compressor as well as the decompressor for special applications, though usually with a reduction in compression. For various combinations of the allowed values for those parameters, the expansion can be larger than for the default settings. The worst case choice of parameters can result in an expansion of at most 13.5%, plus eleven bytes.

The deflateBound() and compressBound() functions can be used to provide an upper limit on the expansion in order to permit the allocation of an output buffer assured to be large enough to hold the entire compressed output. deflateBound() takes into account any deflateInit2() options.
ok, here's an example using the MOD I mentioned before (http://www.phpbb.com/phpBB/viewtopic.php?t=308001" target="_blank - Asynchronous & Dynamic Post Preview with DHTML). It uses a server side script to parse BBCodes et all. It adds very little overhead to the HTTP response.

Writing the following to the posting textarea

Code: Select all

Hello world !
This is a sample. ;)
...and hitting the preview button, it would generate a request like this:

http://www.phpmix.com/phpBB2/dynpreview ... sample.%20;)

The returned data would look something like this:

Code: Select all

<html><body><div id="dynpreview_php">Hello !
This is a sample. <img src="http&#58//www.phpmix.com/phpBB2/images/smiles/icon_wink.gif" alt="Wink" border="0" /></div></body></html>
That is 175 bytes. I'm using Gzip compression and the transfer only involves 170 bytes (including the URL of the image). ;) You can check it here:

http://www.pipeboost.com/GetReport.asp? ... 2520%3B%29" target="_blank
alcaeus wrote: Cross-browser issues? No. There are only two things I noticed...
This is called cross-browser issues in my country. ;)
alcaeus wrote: To me, AJAX is more dynamic than DHTML, but I can also be wrong here, so don't beat me :P
heh, here we are. :P ...AJAX is not more dynamic it's just a new extension to the possibilities of javascript. IMHO, it is already a too young technology not even supported by standards. This is a critical factor as it might change in the future or there might be new technologies to achieve the same result even easier.

The only thing I've found that is better than good old DHTML (or call it what ever, it is just a short term everyone undertands IMHO) is it allows to post forms without messing with the browser history. So it is possible to send large chuncks of data from the client to the server asynchronously. In fact, that'd be a point for the MOD I coded. With just DHTML I'm forced to use GET variables (or I could also use cookies) to send the contents of the textarea, hence I'm limited by the HTTP protocol (or the web servers, not sure here), which might be about 4K.

Still DHTML could have been used to implement the instant search user form or the lock/unlock topic function pretty easily, even supporting more browsers than using AJAX.
alcaeus wrote: I have just started playing around with AJAX a little bit, and I have realized that it's kinda sweet. That's why I asked if it would be in there, and not if they could implement it ;)
Well, it will be there, as it is now. I just think this is not something to go in the core product, as even if you can solve all paths to provide workarounds when javascript is disabled, no compliant browsers, etc. now, there might be new issues in the future (the standard designed using a different approach, browser bugs, etc.) that would break the product. No one stops you from writing a MOD, but not only AJAX should be taken into consideration. Here's an example (http://www.howtocreate.co.uk/loadingExternalData.html" target="_blank) of an implementation that besides AJAX related objects also uses hidden iframes, hence adding more compatibility to the field (still too critical to be part of a product such as phpBB, IMHO).
User avatar
cyberCrank
Registered User
Posts: 560
Joined: Wed Jan 28, 2004 3:38 am
Location: Ethereal Bliss

Re: AJAX support?

Post by cyberCrank »

Jesse has a nice overview and perspective IMO:

http://www.adaptivepath.com/publication ... 000385.php

Plus Whatis's overview:

http://searchwebservices.techtarget.com ... 21,00.html

and Wikipedia's evolutionary overview:

http://en.wikipedia.org/wiki/AJAX

A very nice example of interactive AJAX-type updates as one types in a Google search query is shown here:

http://www.google.com/webhp?complete=1&hl=en

** tis even fun to watch and see what pops up as one types in a query, but the # results is interesting too, although this example shows the interactive responsiveness as does Google Maps with pan and zoom :) **
markus_petrux
Registered User
Posts: 376
Joined: Fri Jun 18, 2004 10:58 pm
Location: Girona, Catalunya (Spain)
Contact:

Re: AJAX support?

Post by markus_petrux »

This one is also pretty interesting, specially the comments:
http://www.quirksmode.org/blog/archives ... se_or.html" target="_blank
PPK wrote: When I first read Jesse James Garrett's article Ajax: A New Approach to Web Applications my reactions were "What a silly name", and "Not really new, is it?" Although both points of critique have been repeatedly and heatedly mentioned in the ensuing discussion, the concept seems to be taking the Web development community by storm. This can mean one of two things: either it's a promise or it's a hype. To decide the case, I offer an annotated link dump.

....
SamG
Registered User
Posts: 1241
Joined: Fri Aug 31, 2001 6:35 pm

Re: AJAX support?

Post by SamG »

I think a lot of people, especially those who compare AJAX and DHTML, are missing Casey's point (and Garrett's) about the whole idea of abstraction.

(I don't say that as an AJAX enthusiast. In fact, I'm more and more inclined to think that to increase emphasis on client-side scripting on the Web is to move in the wrong direction. I'm not at all sure that DOM is such a great platform for Web applications; what a bunch of busywork! I begin to wonder why we don't lobby instead for true standardized APIs/hooks into a browser, and the OS behind it, rather than escalating the use of scripted methods -- including DHTML -- whose uniform support by Web standards is murky at best, by the way.)

At any rate, efficiency and standards aside, I still feel comparisons between AJAX and DHTML often are not seeing AJAX for what it ostensibly is -- a fast engine. But there I go repeating myself ... :)
R. U. Serious
Registered User
Posts: 32
Joined: Mon Feb 11, 2002 2:07 pm
Contact:

Re: AJAX support?

Post by R. U. Serious »

Ajax does not rely on XML, it relies (by the definition of some) on the XmlHTTPRequest Object, which can be used to make http requests and handle the response - and both request and response can be any way you like, XML or not.
One Reason it is in the "name" is that AJAX is, I'll saying it again, a "Marketing Term, not a specification - it is meant to communicate something great and new, and the more buzzwords the more interest. Plain and Simple. And, granted, the people that came up with the idea do indeed use XML, as do some others, but a lot of people don't.
worked fine the very first moment I tested them in IE, FF, Opera and Safari
Last I checked Opera wasn't able to do POSTs and it wasn't able to handle the requests asynchronously. Those are some very serious drawbacks, if you ask me.
Das Kölsch zum Handy.
alcaeus
Registered User
Posts: 66
Joined: Sun Oct 10, 2004 3:21 am
Location: Munich (Germany)
Contact:

Re: AJAX support?

Post by alcaeus »

R. U. Serious wrote: Ajax does not rely on XML, it relies (by the definition of some) on the XmlHTTPRequest Object, which can be used to make http requests and handle the response - and both request and response can be any way you like, XML or not.
Yea...either XML or plain text. To be honest, I'd rather mess around with the DOM XML parser to get the information I want rather than splitting a response array imploded into a single string which gets passed to the request object as plain text. ;)

In fact, using XML is also an indicator if it was successful. One MOD I built just included little modifications to search.php for example, and allows some AJAX features. However, when there's errors, you get a plaintext response. Therefore, once the request is completed I check if the result was XML data, if not I just ignore it and don't worry about it - the PHP script will do that for me once the data is sent to it upon posting the page.

About Opera: I can only say that this was the first time Opera hasn't disappointed me: Opera 8.0 managed to handle everything just like FF and IE did :)

Greetz
alcaeus
Post Reply