ROR的AJAX心得

ROR的AJAX心得

最近用ROR做了一个网站(http://www.bladearena.com)，全部采用了AJAX来处理数据。在这个
过程中积累了一些心得，在这里总结一下。一方面可以与大家分享，另外也让自己不要那么快忘记了：)

首先还是要赞一下ROR，感觉使用起来入行云流水一般，一发不可收拾。在编码的时候经常一上去就觉得
这个怎么简单，那个怎么那样容易。自己的想法往往一出现，就可以马上实现。似乎在一夜之间编程变成了
一件简单而愉快的事情。呵呵，感觉虽然有点夸张，但实际上也差不多就是。

说了那么多，还是来说说具体的一些心得体会吧。
1.关于页面刷新
    AJAX一个重要的用户体验就是页面不会刷新。所以在程序中如果要更新页面上的数据，就只能更新页面某一
部分，而要保持其它部分不动。要怎么实现呢？这就需要把页面分成很多的小块，具体到ROR上就是把页面分成
很多个.rhtml模板。根据我的经验，在一个功能中需要3样东西。一个ACTION，一个.rjs,一个.rhtml。
    (1)ACTION用来处理逻辑，分析提取数据，然后把需要的数据作为类变量(例如：@user)公开出来。
    (2).rjs用来处理页面表现方式。这里面一般用模板替换比较方便。
    （例如：page[:user].replace_html :partial=>'ui/user')
    (3).rhtml用来表现数据。把ACTION公开的数据用HTML方式表示出来。
    (例如：用户：<!---->)
    如上所述，在编程的时候就把很多小的功能通过以上方式一组一组的完成好，然后把它们全部一起镶嵌到
一个页面里，这样就可以很方便的实现了我们的整个系统。

2.关于数据传输的问题
    大家都知道AJAX也是通过HTTP传输数据的，所以数据量的大小也直接决定了页面反应的快慢。因此，在设计
页面的时候就应该尽可能小的划分各个区块，这样在更新数据的时候，只把需要更新的区块更新，不需要的千万不要
多加。

3.div+css
    这要提一下DIV+CSS，它的主要思想是把网页所要表现的内容和风格互相分离。这十分符合AJAX网页
的设计风格。把需要更新的模块分成不同的DIV,让后通过ID进行区分，这样就可以很方便的用我上面说的
方式来处理数据。

4.AJAX分页
    虽然ROR提供了分页，但很明显的是它不是AJAX的使用用的。所以这里就需要自己来做个，就我使用的方法来说。
分成2个部分，数据的显示和分页按钮。
    (1)数据显示就是一个.rhtml，在这里我设置了一个SESSION[:page]变量来存放页码，取数据的时候就通过
这个:page到数据库里面去取，然后把结果显示出来。这个模板很简单，就是一个MODEL的FIND，然后EACH出来就可以
了，其它根本不用管。
    (2)分页按钮对应一个ACTION，这个ACTION的主要作用就处理:page变量，比如增加一页就加1，跳转到第5页
就直接设置成5.然后就是对应这个ACTION的.rjs。这个.rjs其实也就很简单了，就是我上面所说的替换一下数据显示
模板就可以了。这样数据显示模板就会根据新的:page去查询新页面的数据。
    一个AJAX分页也就这样实现了。
   
(这篇文章由风北狼完成于2007-7-11)

评论

4 楼 bencode 2007-07-14  

楼主做的吗？ CSS布局好像不大好哦。 FF中看看新闻页面：）

3 楼 笨笨狗 2007-07-13  

我也是习惯了自己写js，所以rjs就用用常见、简单的得了，大部分还是自己控制比较好

2 楼 liusong1111 2007-07-13  

搜了一下，这个blog开头几个回复跟我意见差不多：
http://blog.zerosum.org/?q=node/47
另发现有人在rjs和REST使用上出了问题：
http://www.railsforum.com/viewtopic.php?pid=22592

我把前面几条引用过来了。

nap 写道

Like most people, I'd be happy to see the framework's impl of all things Javascript become a little less prototype-dependent. Making it pluggable to some extent so that alternative javascript libraries could be used (jquery, yahoo's YUI connection manager, etc) would be excellent. I guess that this may mean standardizing on a 'helper interface architecture' of some sort, some of which could be more RESTful in approach than others.

Justin Jones 写道

At the end of the day, I think it's pretty clear that "merging" Ruby/Rails and JavaScript/Prototype is not exactly a great idea.

It works awesome for simple remote form submits / remote links, but as you get more specific, it tends to break down.

Just take a look at the source of the "major" rails apps (the only ones I've looked at) - anything from 37s and Blinksale. Most of the JS do is written in JS, not in Ruby.

And this coming from someone (me) who isn't even particularly fluent in JS

Dan Kubb 写道

nap: You're right that alot of the Javascript the helpers output doesn't really fit in with the RESTful way of things. Many of those were in place over a year before RESTful Rails caught on.

RJS itself doesn't work too well with REST either. Justin's right on the money with his approach: In many cases it would be better to speak XML and have the JS parse it on the client side, rather than returning HTML/JS fragments. I'm hoping that Jester catches on and fill this gap.

I've actually found something neat about the Rails patching process in that nearly every single patch that's even remotely related to REST has been accepted extremely quickly. I've even had a couple of patches committed to the core within a few hours of submitting them because they added or fixed something related to REST or the HTTP handling.

I think if people can find a way of patching Rails' JS helpers to work better with REST that it'll be accepted quickly. Anything that isn't backwards compatible (like an AutoComplete that works with GET and XML) would fit nicely in a plugin for now.

1 楼 liusong1111 2007-07-12  

我认为需要重新审视RJS的作用。
如果ajax只是简单的做模板替换，用rjs还是客户端的纯javascript差别不大，都是那么一两行代码而已。
但如果控制复杂数据的更新，rjs代码里就既包含了数据,也包含了表现层的控制代码，后者依赖于调用页面上下文，隐约感到“脏”，是不是也有违REST原则？
RJS让使用者不需写javascript代码的优势毫无疑问，但同时：
1. 严重绑定prototype.js家族。虽然rails的一站式让我们无须选择，但就javascript库来说，jquery等后来者更优秀，虽然有plugin支持它，但毕竟不是官方。
2. rjs vs javascript 代码的重用性。我们写的通用javascript,可以封装成单独的js文件被重用到非rails系统中，但rjs显然不行。
3. 学习成本。省了javascript的学习成本，又带来了rjs的学习成本，又是一个典型的成本转移。rjs对于复杂javascript的支持度（它有调用javascript function的表达，但要求使用者对rjs和javascript都要了解）
4. 开头提到的 数据与表现分离原则。我个人更喜欢服务器端返回json，而把控制UI的代码用纯javascript写（这时可以选用喜欢的jquery等）。这样，被外部系统集成的障碍就小很多。比如让google gadget的XMLHttpRequest访问，只需在gadget中引用json.js进行正反向解析。