话题拉的有点远了，换标题继续讨论吧 XD ※ 引述《gpmm (银色)》之铭言： : ※ 引述《TonyQ (沉默是金。)》之铭言： : : 但是相对的也会需要去面对 ajax 真正麻烦的那一部份， : : 那就是你到底需要做什麽，还有你的画面应该在每个ajax状态呈现些什麽。:-) : 终於有时间回了， : 我换个方式解释，T 大听看看对不对， : 原本一般的架构设计是 : 前端：介面 | 定义的介面逻辑与介面反馈 | 发送请求（资料） : 後端：接收请求（资料）| 资料的逻辑处理与请求反馈 : T 大您现在的架构是 : 前端：介面 | 发送请求（资料） : 後端：接收请求（资料）| 处理介面逻辑 + 资料逻辑 | 反馈介面命令 + 资料 : 换句话说，每一个行为的处理统统都交由 server 来做决定， : 试着举个例子，一个计有五列的表格，每列都有一个 checkbox， : 当使用者 click 时，浏览器直接将此 ui request 送给 server 来回应， : 於是 server 可以依据不同的情况（例如 user 的权限足够与否） : 来进行不同的介面回应（於是整列选取并变色，或弹出视窗告诉你无法点选） 原则上是你这样说的没错，不过实际上其实还有很多可以延伸讨论的空间。 （後叙） : 但是这样的好处是什麽呢？ ui 具有动态调节的空间吗？ : 依据这种设计结构，的确 defer 和 muti-ui-command 的结合送出变的非常重要了 : 很好奇 T 大是开发什麽样的网站或着服务或有这麽特别的架构？ : 听起来都是在尝试使用比较特别的技术，好羡慕…ˊˋ server centric 的优点主要在於几点 1.资料的隐密性跟资料逻辑的隐藏，这对安全性来讲是有加分的。 2.使用者无须自行撰写 js code 就能进行最基本的事件处理。 （这个应该是最有吸引力的部份。XD） 3.因为使用者并不是写实际的html ， 所以 ui 比较有机会 port 到别的平台上。 4.比较容易对 js /css 做最佳化。 讲优点当然不能不讲缺点 1.因为是 server centric ，势必要有资料的载体， 过去这些资料都是在前端，而为了作到前後端同步， 所以会有一些资料都是绑在 session 上，记忆体上负担会比较重。 2.流量(traffic) 的部份，需要花很多时间跟心力去作最佳化。 所以才会有我们再讲的这个议题。 ----------------------------------------------------- 基本上目前主要的有在做 server centric 的，大多都是 java 的framework ， 我在想是因为 java 的世界观比较适合做这件事吧。 经典例子应该就是 Google Web Toolkit (GWT) 了，痞子好像很喜欢这东西。XD http://code.google.com/intl/zh-TW/webtoolkit/overview.html 这类的 framework 应该有十来个吧，也包含像 JSF 这类的工具。 ----------------------------------------------------- 不过上面所讲得只是 server centric 的基本挑战而已， 真正的挑战是要如何提供够丰富的介面让使用者来用。 如果开发者以写 html 的思维来写 application ， 那这样的帮助就比较有限，它还是需要写很多的 code 来做一些简单的事情。 而且现在 jQuery plug-in 或其他 js plug-in 这麽多， 总是会有开发者希望整合一些元件。 所以就冒出一个很重要的核心理念就是 designed by component ， 基本上我相信就算不是 server centric ， designed by component 这个概念将会在未来的日子成为一个主流。 ----------------------------------------------------- 什麽是 designed by component ？ html 中的元件太少了，根本不够用， 连最基本的 calendar 都要拉js plug-in。 假设我今天有一个东西 就叫 <datebox id="hello" /> 然後它会自动帮我产生一个textbox ，点击後会有 calendar 冒出来， 我在後端只需要 hello.getValue() 就可以轻松取得使用者所输入的资料， 这样对开发者的负担来讲就降低了。 所以为了要做到这件事情，就必须去写很多的 component (or widget) ， 他会包含 js/html/css/event 这四块， 整合各种需要的介面，以此来达到想要的目的。 於是做了这些事情之後，我们就能达到写 web application ， 就像在写真正的视窗应用程式的效果，这感觉还不赖。 （想像一下写 asp.net 的程式的写法， 但是不用一直换页的感觉，也不用去搞那麻烦的 updatepanel 。XD ） 题外话，我刚接触这类 fw 时有一个疑惑是那 F2E是不是就不被需要了， 但即使是在 server centric 的角度，写 js 这件事情也不是能完全舍弃的， 有些客制化的需求还是需要的，所以 GWT 有 JSNI 可以让使用者自己写， 只是它把写 js 这件事情变得比较算是 optional 。 也可以把 F2E 的人力用在 widget 的开发上，就能够一直累积共用元件， 我觉得这对 F2E 来讲也好，对web世界来讲也好，是双赢的策略。 -- 我一向都是看工作要做什麽就做什麽啊，我之前某份工作还跑去写 rails 咧。XD （题外话， ActiveRecord 是我目前看过最棒的 ORM 模型...） 毕竟 F2E 对很多地方而言，一直都是个很头痛的任务， 虽然很多地方并不了解专职 F2E 有用的地方。 -- 网页上拉近距离的帮手 实现 GMail丰富应用的功臣 数也数不清的友善使用者体验 这就是ｊａｖａｓｃｒｉｐｔ 欢迎同好到 AJAX 板一同讨论。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 114.137.2.106 ※ 编辑: TonyQ 来自: 114.137.2.106 (09/11 23:16)