在开发乐华的员工论坛,前期的试用版本已经放出,目前要先针对后台进行一次完善,然后才能开始下一步的工作。
使用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写一些客户端应用。
无尽的开发啊,一个好的过程,应该从规划开始。