为什么需要ajax(为什么需要工匠精神)

为什么需要ajax,为什么需要工匠精神

内容导航：

为什么要用ajax框架

Ajax是什么工作原理是什么

为什么ajax可以部分刷新页面

JavaEE不再需要Ajax 了吗

一、为什么要用ajax框架

ajax是技术，不是框架，ajax的框架是指这些：dwr或jquery或ext这一类的东西。至于
为什么要用它们呢，主要是它们给我们做了一些封装，使得我们的应用变得简单。

二、Ajax是什么工作原理是什么

Ajax用来描述一组技术，它使浏览器可以为用户提供更为自然的浏览体验。
在Ajax之前，Web站点强制用户进入提交/等待/重新显示范例，用户的动作总是与服务器的“思考时间”同步。
Ajax提供与服务器异步通信的能力，从而使用户从请求/响应的循环中解脱出来。
借助于Ajax，可以在用户单击按钮时，使用JavaScript和DHTML立即更新UI，并向服务器发出异步请求，以执行更新或查询数据库。
当请求返回时，就可以使用JavaScript和CSS来相应地更新UI，而不是刷新整个页面。
最重要的是，用户甚至不知道浏览器正在与服务器通信：Web站点看起来是即时响应的。
虽然Ajax所需的基础架构已经出现了一段时间，但直到最近异步请求的真正威力才得到利用。
能够拥有一个响应极其灵敏的Web站点确实激动人心，因为它最终允许开发人员和设计人员使用标准的HTML/CSS/JavaScript堆栈创建“桌面风格的（desktop-
like）”可用性。
通常，在J2EE中，开发人员过于关注服务和持久性层的开发，以至于用户界面的可用性已经落后。
在一个典型的J2EE开发周期中，常常会听到这样的话，“我们没有可投入UI的时间”或“不能用HTML实现”。
但是，以下Web站点证明，这些理由再也站不住脚了：BackPack Google Suggest Google Maps PalmSphere
所有这些Web站点都告诉我们，Web应用程序不必完全依赖于从服务器重新载入页面来向用户呈现更改。
一切似乎就在瞬间发生。
简而言之，在涉及到用户界面的响应灵敏度时，基准设得更高了。
定义Ajax Adaptive Path公司的Jesse James Garrett这样定义Ajax： Ajax不是一种技术。
实际上，它由几种蓬勃发展的技术以新的强大方式组合而成。
Ajax包含：基于XHTML和CSS标准的表示； 使用Document Object Model进行动态显示和交互；
使用XMLHttpRequest与服务器进行异步通信； 使用JavaScript绑定一切。
这非常好，但为什么要以Ajax命名呢？其实术语Ajax是由Jesse James Garrett创造的，他说它是“Asynchronous
JavaScript + XML的简写”。
Ajax的工作原理 Ajax的核心是JavaScript对象XmlHttpRequest。
该对象在Internet Explorer 5中首次引入，它是一种支持异步请求的技术。
简而言之，XmlHttpRequest使您可以使用JavaScript向服务器提出请求并处理响应，而不阻塞用户。
在创建Web站点时，在客户端执行屏幕更新为用户提供了很大的灵活性。
下面是使用Ajax可以完成的功能：动态更新购物车的物品总数，无需用户单击Update并等待服务器重新发送整个页面。
提升站点的性能，这是通过减少从服务器下载的数据量而实现的。
例如，在Amazon的购物车页面，当更新篮子中的一项物品的数量时，会重新载入整个页面，这必须下载32K的数据。
如果使用Ajax计算新的总量，服务器只会返回新的总量值，因此所需的带宽仅为原来的百分之一。
消除了每次用户输入时的页面刷新。
例如，在Ajax中，如果用户在分页列表上单击Next，则服务器数据只刷新列表而不是整个页面。
直接编辑表格数据，而不是要求用户导航到新的页面来编辑数据。
对于Ajax，当用户单击Edit时，可以将静态表格刷新为内容可编辑的表格。
用户单击Done之后，就可以发出一个Ajax请求来更新服务器，并刷新表格，使其包含静态、只读的数据。
一切皆有可能！但愿它能够激发您开始开发自己的基于Ajax的站点。
然而，在开始之前，让我们介绍一个现有的Web站点，它遵循传统的提交/等待/重新显示的范例，我们还将讨论Ajax如何提升用户体验。
Ajax和服务器端技术毫不相关；DOM模型是Ajax最本质的技术；在使用Ajax控件前理解它们的实现；学好JavaScript ；Ajax点缀：CSS 。
观点一：Ajax和服务器端技术毫不相关 严格的说，与传统web开发相比，Ajax是完完全全的客户端技术。
由于很多控件封装了客户端和服务器端的通信过程，因此很多问题也因通信而起。
事实上，不论何种Ajax技术，服务器端都是返回的一个纯文本流，再由客户端来处理这个文本。
这段文本可以是xml格式，也可以是一个Html片段，也可以是一段JavaScript脚本，或者仅是一个字符串。
服务器端仅仅是作为一个数据接口，客户端使用XMLHttpRequest对象来请求这个页面，服务器端在页面内写入结果文本，这个过程和普通的web开发没有任何区别。
所不同的只是，客户端在异步获取结果后，不是直接显示在页面，而是由客户端的Javascript脚本处理后再显示在页面。
至于各种控件所谓的能返回DataSet对象，Date对象，或者其他的数据类型，都是封装了这个处理过程的结果。
观点二：DOM模型是Ajax最本质的技术
之所以没有把XMLHttpRequest列为最本质的技术，因为本人觉得它实在是太简单了，它只是可以让浏览器在后台请求一个页面，并将其内容交给JavaScript处理。
真正的核心应该是：DOM模型，即文档对象模型。
在DOM模型里，Html标记都被认为是一个对象，例如：div对象，table对象等等。
DOM模型就规定了这些对象所具有的属性、方法和事件。
通过这些性质，可以对一个已经显示于浏览器的页面进行内容的修改，例如增加节点、修改节点位置，删除节点等等。
而不仅仅是一个innerHTML属性这么简单，虽然这是一个很有用的属性。
观点三：在使用Ajax控件前理解它们的实现 使用Ajax控件的确可以提高效率，但如果你空中楼阁般使用控件，那就得不偿失了。
从一个控件换到另外一个控件又会有一个漫长的学习曲线。
所以应该从底层了解其，况且Ajax实在不是什么高深的技术。
其实任何东西的最底层其实都是简单的，但如果封装了这些底层的东西，事情会变得复杂和难以理解。
以为例，它的定制特性可以使得只要在方法前加上[ajax
method]类似这样的标志就可以称为一个异步方法，相信这使得的Ajax开发显得更加“高效”或者是“神秘”，而更多的事情则被封装了。
同样记住一条，任何对服务器端的请求仅仅是返回纯文本，我们不一定要依赖于封装好的处理过程，而完全可以自己来实现。
观点四：学好JavaScript
在大多数人看来，JavaScript总不是那么一种正规的语言，随便copy一段就碰巧能运行，学过c之类的人，一看也能看懂，而且在浏览器中常常有脚本错误提示，所以潜意识觉得总不能付之以大任。
事实上，要学好Ajax，这就完全是一种错误的看法。
javascript作为一种脚本语言，其语法的确不是很严格，但并不妨碍其完成诸多复杂的任务，没有JavaScript，就没有Ajax。
所以本人强烈建议，学Ajax前，一定要好好研究一番JavaScript，一般来讲，如果能顺利看懂prototype框架的代码（如：），你的JavaScript水平就基本过关了。
同时对DOM模型也可以算有一个基本的了解。
观点五：Ajax点缀：CSS
用JavaScript控制CSS其实很简单，基本上每个DOM对象都有一个style对象，只要把css属性里的”-“去掉，并让随后的字母变为大写就可以作为属性使用了，例如：dColor=”#f00”;在css是：选择符
{background-color:#f00}

三、为什么ajax可以部分刷新页面

这个就看ajax的机制了，你需要看看传统网页刷新和ajax刷新的区别
首先要理解同步和异步的概念。 Ajax是异步请求后台返回所需的结果，然后在前台通过修改DOM对象来达到局部刷新的效果。不知道这样解释你理解不理解。
以 拓灿科技 结合php+ajax的案列看 传统页面与ajax页面有非常多的不同，然而其中最根本的区别就是更新范围。tuocan
在过去，即使是页面中极小部分的更新，也必须将整个页面回传给web服务器，处理完毕后再将整个页面传回客服端，浏览器刷新，这样势必造成效率损失。

四、JavaEE不再需要Ajax 了吗

答：3年前，“Spring之父”写了一本在Java界引起轰动的书：《ExpertOne-on-
OneJ2EEDevelopmentWithoutEJB》。这本书阐述了EJB作为J2EE核心技术所带来的意义与价值，但作者用了更大篇幅介绍EJB的一些缺陷与不足，并提出了WithoutEJB的解决方案。正是由于“J2EEWithoutEJB”这个激动人心的口号及这本书奠定的基础，导致了SpringFramework这个经典轻量级框架的诞生。2年前，Ajax开始进入人们的视野。时至今日，Ajax已经成为一个红得发紫的技术。但是今天，我想说一句：JavaEEwithoutAjax。Ajax的“原罪”Ajax为什么这样红?有人说，是因为起了个好听易记的名字(比如荷兰著名的Ajax球队，即阿贾克斯);也有人说，是因为Google全新的Ajax应用产品给人们带来的超酷体验(比如伟大的GoogleMaps、GMail等)。确实如此，Ajax能够如此流行的最主要原因就是它带来了更好的用户体验，改变了人们对传统Web应用的不佳印象。然而，即使Ajax的狂热Fans也不得不承认的是，从技术层面上来说，Ajax并没有带来什么新鲜的东西。它本质上是一种新瓶装旧酒的技术，好处是通过JavaScript与DHTML提供了一种异步编程模型，从而使Web应用给客户带来了更好的人机体验。正如我在去年引起大家争论的拙文《Ajax，只是一种过渡技术》中表述的：Ajax解决问题的层面较低。或者说，它解决问题的方法与手段，很难形成一种可高度抽象的框架级解决方案。并且，正是因为Ajax基于JavaScript，因此不可避免地带来了JavaScript的诸多缺点，譬如：跨浏览器是一场噩梦对搜索引擎的支持不好干掉了Back、History等按钮(尽管我并不认为Back、History是什么好东西)开发与维护成本过高要Java,不要JavaScriptWeLoveJava,NotJavaScript。套用毛泽东的惯用句式就是：“要Java,不要JavaScript”。相信很多读者看完这个标题也许会不以为然，但这句话却代表了许多J2EE开发人员的心声。众多Java工程师都对Java有一种近乎偏执的喜爱，他们热爱Java的简洁与优雅。但一旦让他们去进行JavaScript的开发，却往往会不知所措：过度灵活的语法，无法通过编译器进行语法校验，缺乏良好的调试工具等等这些，都会让人们对JavaScript畏手畏脚，更遑论Ajax的开发。一句话，Java社区需要Ajax，需要它来提升基于JavaEE的Web应用的人机体验;但是，人们并不喜欢Ajax目前的开发模式。无疑，我们需要一种新的解决方案。谁来拯救JavaEE的Ajax?我给出的答案是JSF。目前，关于JSF的一种流行说法是“悲剧人生：Sun让JSF光着身子降临到JavaWeb世界”。然而，我的看法却是：作为一种革命性的服务器端组件技术，JSF犹如早晨八九点钟的太阳，前途不可限量。让事实说话，我们先来看看JSF请求/响应过程的标准生命周期：图1：JSF的生命周期通过上图可以观察到，任何一个JSF“FacesRequest”请求，经过RestoreView、ApplyRequestValues、ProcessValidations、UpdateModels、InvokeApplication等阶段以后，产生了一个“RenderResponse”返回给客户端。那么，常规JSF引擎是如何实现上述过程的呢?图2：常规JSF引擎的请求与响应过程回顾一下常规JSF引擎针对请求与响应的过程：首先，客户端请求某个资源，产生一个FacesRequest;服务器端接收到此请求以后，经过一系列后台处理，产生一个FacesResponse。我们注意到：响应的Content-
Type是text/html，而产生的内容主体是一段HTML文本;浏览器在接收到HTML文本以后，进行整个页面的渲染与刷新。无需写Ajax代码的AjaxEnabled应用我用自己开发的JSF引擎，这样处理上述过程(详见参考资料)，如下图所示：图3：OperaMasksJSF实现的请求与响应过程首先可以观察到，FacesRequest的发出是基于“x-requested-
by:XMLHttpRequest”，也就是说，这是一个Ajax请求，而该请求在到达服务器端以后，服务器端所产生的FacesResponse同常规FacesResponse相比也发生了变化：Content-
Type不再是text/html，变成了text/javascript;并且，响应的主体也不再是html文本，而是一堆script脚本。浏览器在接收到响应以后，再也不需要进行整个页面的渲染与刷新，而只仅仅需要执行这段脚本内容，将页面的控件进行更新即可。显而易见，通过上述JSF技术，我们获得了：基于Ajax的请求、应答、及页面控件的更新数据传输量明显减少避免整个页面的刷新，更好的用户体验系统保持敏捷、高效换言之：任何标准JSF应用，只需将其在OperaMasksJSF引擎上运行，就可以达到这样的效果。我们并没有写任何一行Ajax的代码，但是，我们的应用却是自然而然的AjaxEnabled的应用。大道至简，大象无形。奥妙所在：JSF的Render机制为什么可以这样?JSF组件只是特定状态和行为的载体，而组件以什么形式去和用户交互，是完全可定制的、独立于该特定的表现语言，可以是HTML、WML或者其他形式;具体是什么，可以通过指定JSF组件的RenderKit来实现，而每一种RenderKit，对应于组件作者写的同一风格和形式的一系列Render。比如，如果想在网页中实现图表功能(Chart)，MSIE有VML，Gecko和Opera有SVG;而在服务器端只需要简单地判断一下浏览器类型，就可以选择一个RenderKit，生成不同的客户端表现来完成相同功能?D?D这是用常规JSP技术很难完成的任务。通俗的说，JSF组件可以翻译成任何你想要的形式。So，JSF框架比现有其它开源框架具有更强的生命力。上文所述的OperaMasksJSF，其容器级别Ajax实现，正是灵活应用RenderKit的具体案例。从容器级别对Ajax予以支持的JSF引擎我们提出的JSF是直接由JSF容器来处理Ajax请求的，它会根据请求类型来判断这是一个正常HTTP请求还是一个Ajax请求：如果是常规HTTP请求就运行JSP页面，生成页面文档(特定的，对于AjaxRenderkit，要加入一些Ajax基础JavaScript代码);如果是Ajax请求，服务器对请求参数正常解码，并执行JSF中除页面输出阶段以外的所有其他阶段，生成一个JSF组件树。一直到这一步为止，处理方式与对普通HTTP请求的处理完全一致，唯一不同的是：在随后RenderResponse阶段，容器除了调用组件作者写的Ajax功能Renderer以外，更重要的是在生成响应页面时，会过滤掉一切不会变化的静态内容?D?D也就是说，静态内容不会生成到响应页面中去，而对每一个动态内容则会生成一个相应JavaScript代码(可以更进一步优化为只有变化了的动态内容才处理)。这样，传给客户的Ajax应答实际上是由这样一些JavaScript语句构成。在Ajax响应返回到客户端时，就可以自动由Ajax回调函数执行这些JavaScript语句，完成对页面即时的、局部的更改，而不需要刷新整个页面。依赖JSF组件的具体功能，甚至可以改变页面的外观。而整个Ajax机制由JSF引擎提供，对用户完全透明。实际上，在JSF规范中JSF页面输出阶段所采用的RenderKit是可替换的，默认的HTML_BASICRenderKit输出的是标准HTML语法，不包含任何JavaScript代码。我们提出的JSF引擎实现了一个AjaxRenderKit，可以在HTML文档中嵌入JavaScript代码来实现Ajax特性，而替换RenderKit只需要修改配置文件即可。简单地说，这种JSF引擎为每个标准组件都实现了相应的AjaxRender，比如对UICommand组件，其AjaxRender会在onclick事件中加入JavaScript的Ajax提交代码，向服务器提交Ajax请求。通过这种方式，任何一个包含标准JSF组件的Web应用，都可以通过只更改RenderKit配置为Ajax来实现Web应用Ajax化。而对于第三方的组件，可能本身并不支持Ajax，但使用一个名为的标签，就可以立即将这个第三方组件转换成AjaxEnabled。例如，Apachemyfaces的Tomahawk项目提供了一个Tree组件，这个组件本身并不支持Ajax，每当按下一个Tree结点都将重新刷新整个页面。使用标签后，则只刷新Tree部分，而不刷新页面的其他部分。当然更好的方式是，提供一个本身就支持Ajax的Tree组件，以减少冗余数据的传递。关于标签的原理，有兴趣的读者可以参考OperaMasksJSF的源码，这里就不再一一赘述了。综上，JavaEE需要Ajax，但并不需要传统的Ajax开发模式。通过我们提出的OperaMasksJSF技术，我们不再需要知道什么是Ajax，而我们的应用却是自然而然的AjaxEnabled应用。因此，我们认为：JavaEEWithoutAjax!