Ajax是为了应对让人不耐的WebApp的高延迟而搞出来的一套技术框架。
原始的WebApp的Browser和Server是串行运行的，一边工作时，另一边等待。这浪费了整个系统的运算能力。Ajax在Browser端引入一个执行引擎，它一边应付user的请求，一边把某些必须交给服务器处理的东西背地里传送给服务器，同时背地里把结果准备好（接受服务器端的数据），展现给客户。
这极大地增强了WebApp的表现能力。对于大多数的用户交互都会比较自然的支持。
Ajax涉及到的几个技术焦点主要是Javascript（提供可响应的UI，在WebPage上提供交互特性）、XMLHttpRequest （HTTP收发引擎、不打扰用户界面的那种）、XML（用来封装B和S之间交互的数据）。这些技术都是常见的，标准的或者事实上的标准。
对于JS和XML，很多人都颇有微词，我倒是觉得无所谓。这些毕竟都不是影响整个架构的东西。
这里面唯一不太明朗的东西是：异步用户交互模型。我举个例子说明这个问题：
我正在操作Ajax增强的WebUI，我跟UI有个交互A，UI立即给了我一个响应，爽。我又有一个交互B，可是……可是这个需要Server参与才能完成，这时候差异就出现了，UI通过XMLHttpRequest背地里发送给Server，这时候UI怎么响应呢？是不是仍然容许我进行交互C，应该是容许的，毕竟引入Ajax就是这个目的。假设它容许我进行交互C，注意，这时候交互B仍然没有关闭，这意味着什么？这意味着有两个并行的交互。这时候，交互 B的真正响应（或者说最终响应）来了，我正在关注交互C，怎么办？打断交互C，切换到交互B？还是什么别的？更复杂的是，交互B最终宣告：交互C是不被允许的！这下可热闹了。是不是我们应该避免并行的交互？也就是交互B完成以前不允许启动一个新的交互C？
所以，引入Ajax以后本身不是问题，问题是我们怎么应对由此带来的UI交互方面的复杂性问题。至少到现在为止，我还没有想明白怎么办。
可能的想法是把交互分类，一类是请求串行的，一类是可以并行的。这类似于EJB或者COM+中的组件对于事务的请求。：）
原始的WebApp的Browser和Server是串行运行的，一边工作时，另一边等待。这浪费了整个系统的运算能力。Ajax在Browser端引入一个执行引擎，它一边应付user的请求，一边把某些必须交给服务器处理的东西背地里传送给服务器，同时背地里把结果准备好（接受服务器端的数据），展现给客户。
这极大地增强了WebApp的表现能力。对于大多数的用户交互都会比较自然的支持。
Ajax涉及到的几个技术焦点主要是Javascript（提供可响应的UI，在WebPage上提供交互特性）、XMLHttpRequest （HTTP收发引擎、不打扰用户界面的那种）、XML（用来封装B和S之间交互的数据）。这些技术都是常见的，标准的或者事实上的标准。
对于JS和XML，很多人都颇有微词，我倒是觉得无所谓。这些毕竟都不是影响整个架构的东西。
这里面唯一不太明朗的东西是：异步用户交互模型。我举个例子说明这个问题：
我正在操作Ajax增强的WebUI，我跟UI有个交互A，UI立即给了我一个响应，爽。我又有一个交互B，可是……可是这个需要Server参与才能完成，这时候差异就出现了，UI通过XMLHttpRequest背地里发送给Server，这时候UI怎么响应呢？是不是仍然容许我进行交互C，应该是容许的，毕竟引入Ajax就是这个目的。假设它容许我进行交互C，注意，这时候交互B仍然没有关闭，这意味着什么？这意味着有两个并行的交互。这时候，交互 B的真正响应（或者说最终响应）来了，我正在关注交互C，怎么办？打断交互C，切换到交互B？还是什么别的？更复杂的是，交互B最终宣告：交互C是不被允许的！这下可热闹了。是不是我们应该避免并行的交互？也就是交互B完成以前不允许启动一个新的交互C？
所以，引入Ajax以后本身不是问题，问题是我们怎么应对由此带来的UI交互方面的复杂性问题。至少到现在为止，我还没有想明白怎么办。
可能的想法是把交互分类，一类是请求串行的，一类是可以并行的。这类似于EJB或者COM+中的组件对于事务的请求。：）
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
