AjaxClientEngineDiscussion 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 * ''"XMLHttpRequest object can retrieve and submit XML data directly, all in the background without refreshing the page. With this object you can convert retrieved XML data into HTML content using JavaScript, rely on the client-side Document Object Model (DOM) to read the XML document node tree and compose HTML elements that the user sees."'' ---- '''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 "res.setContentType("text/xml");" * set header content type, else IE client fails "get rid of warning on Cross site scripting - MS sites" * have your web page and the XmlHttpRequest URL in the same domain. "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" * "http://domain.com/..." would not work if the "www" prefix left out ---- '''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 page. ---- '''Why use XML''' JavaScriptObjectNotation mentioned as an alternative in a discussion thread to the anchor article. One person suggested reusability in clients without JavaScript 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." ---- '''WebApplicationSecurity considerations''' 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?'' To the first question: Not necessarily. AJAX is about improving the user experience of applications that would otherwise be implemented mainly using raw HTML on the client side, with minimal or no Javascript and certainly no use of XMLHttpRequest. The underlying server-side functionality, including security considerations, ''should'' 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, AjaxWebApplications ---- CategoryWebBrowser