Studying & Summarizing

对于何时使用脚本，觉得一般做法如下：非成型模块使用，非关键模块使用，原型实现模块使用，无极端性能要求的模块使用。这里要提一点，好动西不是设计出来的是改造出来的，设计是给下次改造用的。因为事实上不断变化的东西无法预先提供完美的设计。对于一些新的未成熟的模块，由于需求、设计、甚至实现本身修改平凡，需要能够提供一套适应小步快走的工具。web层是最典型的情况。   那么具体选择何种脚本，如何用脚本实现

之前的实验学习当中已经对RingoJs的容器集成有了定制，利用web的Listener完全可以初始化js容器，以替换JsgiServlet的实现。同时使用holder方式（偷懒方式）维护这个应用唯一的js容器。现在我们要利用这个容器拓展出一个使用的框架功能，plugin模块。源于对wp的羡慕    对于php的经典开源产品wordpress估计很多人知道或者用过。他之所以被

参考：http://www.ringojs.org/tutorial/stickapp.mdstick是基于jsgi标准开发的web框架。其主要实现了jsgi的middleware相关的功能。具体功能如routing，session获取等等。从java类比来看，jsgi标准其实定义了一个与javaweb类似的机制。其中middleware类似filter可以链式一次执行最后进入app-

这次内容是我比较感兴趣的部分，模块化就是依靠这两块内容。通过他们，Ringo提供给了相当好的类插件的功能（node.js的npm也与这个有关）。我的计划是可以利用这个机制在javaweb上提供一个类似wordpress的plugin插件功能模块。  在了解的过程中，需要要理解package以及module在require时的查找路径方式。  ringo的模块与包的实现与node.j

与nodejs vertx 等平台类似，Ringo最常见的应用方向是用于web开发。这里参考官方材料做一些简要说明。官方可参考资料：http://www.ringojs.org/tutorial/Ringo外部包安装：http://www.ringojs.org/tutorial/dependencies.md首先最常见的web开发第三方module包括：stick

Ringo 入门(一)：为何学Ringo？其实源于对javaweb开发以及动态调试的不满，以及对OSGi是无奈，还有node.js所给的压力。最终在上帝的嘲笑下，思考得到了启示。那么其他啥的就不废话了。首先是官网：ringojs.org。资料不多，但是源代码同样不多。安装初次运行：jdk5以上推荐java6/jdk6以上（JAVA_HOME等环境变量设置好）

从这篇开始会逐渐介绍集成改造Ringo.js成为我心目中的东西，而不光是学习使用。  ringo.js作为一个基于jvm的运行时，与java交互是非常重要的部分。但是，官方文档主要描述ringo作为运行时如何利用底层java库。而我其实需要的是ringo如何嵌入到已有java运行框架。  找了半天，终于有一个切入点：jsgi集成。  jsgi：  jsgi是啥？osgi？不是，

就像上回所讲，官方提供了一个样例JsgiServlet。虽然已经在其上stick矿建，但是就个人看来，这个东西确实类似一个样例。 如果使用serlvet作为js容器（ringo-engine）的载体，那么势必一个webapp可以配置多个servlet，也就是多个js容器。这种方式会导致开发人员在不熟悉环境的情况错误的开发判断。其实，如果要方便开发，那么就应该至少提供一个较为但单纯的环境。降低入

开始时遇到一个问题，js脚本文件是utf-8格式，但是其中内容显示到网上就变成乱码。经过研究基本解决。但是这个应该是ringo的一个bug或者说一个待改进的地方。    配置中没有字符集的设置。对于老外可能没啥，但对于用中文的我们可是极大问题。v0.9版本中，其读取js文件无法指定字符集只能使用操作系统的默认字符集。    其实查看Resource模块中，其实他的资源读取模块是有指定字符集

抱怨过了，骂过街。那么重要的是我们其实需要解决问题。方向也在node.js的压力下出现：jvm上内嵌类似nodejs的js容器。事实上，这种东西java也早有了。rhino，rhino可能是最早在服务端运行js之一，而且早在java1.4时期就是我就尝试用过，java6变成java标准实现的一部分。但是对比nodejs的npm，他的周边库少的可怜。nodejs为何有如此强大的社区，这要归功

长期以来从企业开发到早期的互联网开发都有一个情况。后台仅选择一种静态语言开发，而这个情况都沿用到几乎所有框架中去。当然，javaer也也可以说基础技术平台（1.6之前）并不支持多语言，或者至少官方不支持。另外一种论调是，后台多出1中语言就多一些麻烦，简单就是合理的。可是事实上，经过长时间的观察发现，如果任何东西都用java语言区实现有些情况会的十分的低效。尤其，java被过度设计这个问题笼罩由来已

如何低效？我们来看一下struts1到struts2的使用案例。struts1 04年的时候属于巅峰期，其设计理念就是所谓的mvc。将界面的流控制、展示效果、数据都分离开来。似乎很不错。但是事实上呢？开发人员不但需要理解发杂的跳转配置（ajax尚未流行）、数据配置、还要任务理解tag的功能才能做好一个web应用。况且这些都是必须基于必须理解jsp、servlet等基础原理(可惜很多人这部分反而明白

设计者很理想，弄得开发者很骨感吧，过度设计了。事实上，对于很多应用需求的变化不可避免，这也是新一代所谓极限编程的理念。当然，我这里只是对工具做判断。理念落地也需要研究具体操作与工具。为适应变化，应该对原有的工具做调整。在web所谓action层面用动态脚本是最小范围的实践。除了action层外，部分service以及dao都可以用，可以一定范围内混用。当然，在某些情况下载一个脚本函数内完成所有这些