在上篇RIAWork的简要介绍篇中，已经提及RIAWork的重要目标之一就是为界面和交互的灵活变化提供支撑，在这里来看看界面和交互在实际项目中的变化情况以及RIAWork是如何提供对于其变化的支撑的。
界面变化
在实际的项目中，即使是同类的项目，在各个企业甚至各个部门都有对于不同界面的需求，例如有些企业喜欢蓝色、有些喜欢淡蓝色等等的，有些则关注是国字形布局抑或其他各类布局，总之是各种各样的需求都在不断的产生，稍微的总结有以下几种情况：
1、界面风格的变化需求
体现出来的有界面颜色、界面中元素的颜色、样式等的要求。
2、界面布局的变化需求
体现出来的有对于界面的布局的要求。
在实际的项目中，当发生之上的两种变化的时候，通常都要耗费极大的精力去做界面的集成，特别是象以前采用jsp的那种系统，在重新进行界面的集成时还得非常小心，才能避免重新集成界面后造成功能的影响，当然，一些做的比较好的公司能够通过完全用css来控制界面风格、布局的方式来减少这两种变化带来的影响，但其实很多情况下仅仅通过css还无法完全做到足够灵活的控制来支撑用户对于界面的需求，RIAWork致力于解决这两种变化带来的集成的工作量，同时保证对于原有功能的无影响，那么RIAWork是怎么做的呢？
在RIAWork中第一种方式也是采用css的方式来控制界面风格以及布局；
另外一种方式则是RIAWork的特点，RIAWork强调对于html的无污染性，其实这只是一个很模糊的说法，准确的说是RIAWork强调对于界面html的无污染性，这里的区别在于界面html指的是用系统原型图切割形成的html，而不是还需要手工编辑修改的html，这点体现了RIAWork和JSF+Facelets以及Tapestry的不同点，Tapestry以及JSF+Facelets也非常强调对于html的无污染性，但它仍然需要在html的元素上增加自定义的属性，如jcwid这样的属性，而在RIAWork中则不需要，这样的话就完全没有了html的手工编辑的必要性，自然就将界面集成的工作几乎降为了零，在RIAWork中可以直接采用类似riawork?page=index.htm这样的方式来访问index.htm，即时的看到系统的新的界面效果；这里其实也体现了RIAWork强调的静态以及动态处理的分离上，保持了html的静态性质，将其动态性质进行了剥离，我将这种方式称为对于无侵入性的decorator方式，而Tapestry、JSF+Facelets的方式我称为带有侵入性的decorator方式，而采用tag的方式我认为根本就不是decorator的方式，而是彻底的替换方式，后两种方式都让html纯静态的性质被污染，导致了静态和动态的变化产生的互相影响。
对于RIAWork本身提供的基础设施控件，如丰富的表格、Grid则可通过css甚至替换其html的方式来形成新的风格、布局的控件。
交互变化
交互变化在实际的项目中也经常出现，而这点是很头疼的一点，因为交互的变化通常来讲带来的还不仅仅是象界面变化那样的静态性质的变化，有些时候还会带来系统处理的变化，典型的如将一页填表的方式变化为多页向导的填表方式，这种交互变化在系统中发生时往往会很麻烦，需要对页面、代码通通做改变，又如用户希望将界面上的一个下拉选择变成弹出选择，这也需要花费你一点时间去做到，而在RIAWork中，这些交互的变化也会变得很方便就进行调整，在RIAWork对于交互的变化一律归入动态变化性质，对于动态变化性质的东西，均通过管理端进行调整，在管理端中可选择界面元素的交互行为，如向导式的交互行为、下拉交互、弹出交互、链接式交互等等，当然，RIAWork不可能能够提供对于所有交互行为的支撑，这就需要通过实践来不断的提炼交互模式，不断的充实到RIAWork中，关于RIAWork的扩充在后续的介绍中再详细描述。
通过对于RIAWork对于界面以及交互变化的介绍，突出了RIAWork的一个重要特征，就是静态性质以及动态性质的分离，不再支持象以前asp、jsp这些服务端脚本语言提供的静态和动态一起绑定的形式，一个基本的职责分离的原则。
对于界面以及交互变化的支撑，是RIAWork的核心目标，也是RIAWork把用户当上帝，重界面和交互原则的重要体现。
后续文章预告：
RIAWork介绍之二：静态以及动态性质的分离处理
RIAWork介绍之三：RIAWork的扩充以及扩展
RIAWork介绍之四：RIAWork的开放性
RIAWork介绍之五：RIAWork的灵活性以及智能性
RIAWork介绍之六：RIAWork的动态部件
RIAWork进展
进行中：Velocity for js；Roadmap。
计划中：成员的确定以及讨论；RIAWork网站的建立；开发、部署以及演示环境的搭建；M1工作的开展。