在开发乐华的员工论坛，前期的试用版本已经放出，目前要先针对后台进行一次完善，然后才能开始下一步的工作。
使用RoR开发，是一件快乐的事情，他很快，所以你的念头闪的更快。很久没有正经的做一个网站的后台了，何况是一个论坛。我的确需要检讨，这次缺乏必要的规划，加上最近总是精神恍惚的，我也不知道为什么，总是打不起精神。
今天犹豫了很久，究竟是Ajax还是传统HTML，从开始动手的时候的就开始犹豫。以过去在.net的经验，开发Ajax的东西是很吃力的事情，所以起初是倾向于HTML的。可是因为RoR实在是太容易使用Ajax了，remote类的标签拥有一种奇怪的魅力，让你不自然的就加上了，于是Ajax又开始了。所幸的是，RoR没有.net那样多样性，毕竟Rails能选择的方式不多。一天时间，已经完成整个后台数据库操作的框架。然而因为过程中犹豫于两种实现方法中，使得最后做出来的东西，不三不四的。
也许传统的开发人员会感到奇怪，为何有这或那的犹豫，又为何对不三不四感到不满？实现不就好了吗？
Ajax的真正魅力在于将客户端状态持有在JS的对象和变量中，这样间接减少了环回客户端和服务器端之间无谓的通信。在Rails中实现Ajax，从数据库到客户端输出数据，无非两条途径：1、服务器端生成格式化的数据，可以是XML（废弃N年了），可以JSON，客户端负责处理如何组织、渲染、解释这些数据，这样也更符合客户端和服务器端之间的假设。2、服务器端从数据库取出数据（一个时间），再按照模板将数据渲染（另一段时间），最后塞出给客户端解释。
通过tail开发记录，可以看到服务器端处理确实存在两端时间：Completed in 0.07600 (13 reqs/sec) | Rendering: 0.02200 (28%) | DB: 0.01000 (13%) | 200 OK。
要能通过JS持有客户端状态（非cookies），要求页面不跳转（即使跳转，也必须记录关键点的状态）。目前考虑节省时间，主要是使用第二种Ajax的处理，将页面划分块，然后刷新不同的块。不过，现在很乱了，太乱了，唉.....要从头开始了。而且我也没兴趣去写过于繁琐的JS，我更乐于用JS写一些客户端应用。
无尽的开发啊，一个好的过程，应该从规划开始。
使用RoR开发，是一件快乐的事情，他很快，所以你的念头闪的更快。很久没有正经的做一个网站的后台了，何况是一个论坛。我的确需要检讨，这次缺乏必要的规划，加上最近总是精神恍惚的，我也不知道为什么，总是打不起精神。
今天犹豫了很久，究竟是Ajax还是传统HTML，从开始动手的时候的就开始犹豫。以过去在.net的经验，开发Ajax的东西是很吃力的事情，所以起初是倾向于HTML的。可是因为RoR实在是太容易使用Ajax了，remote类的标签拥有一种奇怪的魅力，让你不自然的就加上了，于是Ajax又开始了。所幸的是，RoR没有.net那样多样性，毕竟Rails能选择的方式不多。一天时间，已经完成整个后台数据库操作的框架。然而因为过程中犹豫于两种实现方法中，使得最后做出来的东西，不三不四的。
也许传统的开发人员会感到奇怪，为何有这或那的犹豫，又为何对不三不四感到不满？实现不就好了吗？
Ajax的真正魅力在于将客户端状态持有在JS的对象和变量中，这样间接减少了环回客户端和服务器端之间无谓的通信。在Rails中实现Ajax，从数据库到客户端输出数据，无非两条途径：1、服务器端生成格式化的数据，可以是XML（废弃N年了），可以JSON，客户端负责处理如何组织、渲染、解释这些数据，这样也更符合客户端和服务器端之间的假设。2、服务器端从数据库取出数据（一个时间），再按照模板将数据渲染（另一段时间），最后塞出给客户端解释。
通过tail开发记录，可以看到服务器端处理确实存在两端时间：Completed in 0.07600 (13 reqs/sec) | Rendering: 0.02200 (28%) | DB: 0.01000 (13%) | 200 OK。
要能通过JS持有客户端状态（非cookies），要求页面不跳转（即使跳转，也必须记录关键点的状态）。目前考虑节省时间，主要是使用第二种Ajax的处理，将页面划分块，然后刷新不同的块。不过，现在很乱了，太乱了，唉.....要从头开始了。而且我也没兴趣去写过于繁琐的JS，我更乐于用JS写一些客户端应用。
无尽的开发啊，一个好的过程，应该从规划开始。
