concerns itself mainly with opportunities, problems and solutions related to the use of XmlHttpRequest
object as the Ajax client engine. I understand there are other similar but lesser used alternatives (e.g., MacromediaFlash
) which will be left out.
From the web somewhere
Anchor article - "Very Dynamic Web Interfaces" at http://www.xml.com/lpt/a/2005/02/09/xml-http-request.html
The above was referenced by the ground-breaking Jesse James Garrett article listed in the parent AjaxWebApplications
page. It appeared to be an article that generated lots of discussion at XML.com. Further references were made there about various considerations, some are listed here in sections below for further exploration.
Errors, Omissions and Improvements to the anchor article
Remarks below all sourced from various comments to the base article
- set header content type, else IE client fails
"get rid of warning on Cross site scripting - MS sites"
"Mac users of FireFox
and Safari need code change in checkName function'
- test sb "if(response == 1)" where the number should not have quotes around it
"Need www in URL"
InternetExplorer Ajax without ActivexTechnology
Further reference article at http://weblogs.asp.net/mschwarz/archive/2005/08/24/423495.aspx
See also how PhpLanguage
, using inner HTML and dynamically added "script tag", to get AJAX without ActiveX. See note in main AjaxWebApplications
Why use XML
mentioned as an alternative in a discussion thread to the anchor article.
as reasons to using the bloated XmlLanguage
. But JSON is available in lots of languages.
Thread safety considerations
One person remarked on the concurrency problem of the simple example in the anchor article. He suggests read up on "JS closure methodology" at http://jibbering.com/faq/faq_notes/closures.html
. Others had problem with getting data out using the "inner function" approach.
DOM3 standards supported widely (outside of MSIE)
The commentator said something like "And if that is used, then coding to support browsers (including MSIE fork) is simplified."
A respondent to the anchor article suggested WebServicesSecurity
is required on top of what is presented. He was using XmlHttpRequest
to process SoapProtocol
messages, and complained that only Office03 MSXML parser kit has some desired security features, and that may not stay available in a future version.
Would use of AjaxWebApplications expose application logic to a much wider audience that would otherwise be protected on the servers? If so, would that have assisted people with intentions to deceive through SocialEngineering measures?
be essentially the same. Therefore, I am not clear how client-side implementation issues would necessarily expose application logic to a wider audience, any more so than server-side logic would be exposed to a wider audience on any given non-AJAX Web application. Perhaps I've misunderstood the question?
To the second question: Successful SocialEngineering
will obtain (for example) the same system user IDs and passwords whether AJAX is used or not. AJAX is irrelevant in this case. However, again I suspect I may have misunderstood the question.
See also WebApplicationProblemDomain