上一篇我们聊了如何用Java语言构建一个应用服务器。今天我们聊一下，如何更优雅的生成一个动态的信息页面。
在C/S客户端年代，事件驱动型的开发模式给大家留下了太深的印象了。控件拖拽、所见即所得、编写事件代码，每个使用过VB或者PB的人大概都会有爽的感觉。
在B/S的时代，美好再也没有了。我们必须得明确的认识到，哪些是在浏览器运行的，哪些得要在服务端运行，而且这之间需要经过Http的网络传输，是有性能代价的。
但是追求美好的脚步从来没有停止过。从最早的Asp.Net体系开始，微软为大家构建了一个横跨浏览器和服务端的组件体系，几乎让我们感觉不到跟C/S软件之间的开发区别。可惜微软的代码对我们来说是个黑盒，具体实现不得而知，更可怕的是，当我们想扩展一些自己的实现或优化的时候，只能说不太容易。自由和封闭从一开始就是个矛盾的选择，犹如安卓和苹果。
开源体系其实也有类似的尝试，比如JavaEE的JSF框架。我们先不去研究他的具体实现，先想一下假设我们自己来，我们怎么去设计。
首先，在Html端得有一套组件体系，我们需要把每个UI组件抽象出一个Root类，这个UI组件得能自己渲染Html代码，同时能接受界面点击等事件。UI组件还得有一个组合类，可以允许包含其他子组件。每个组件还得允许他的子类可以实现自己的渲染和事件处理逻辑。
然后，我们在服务器端，也得实现一套对应的UI组件体系。当Html被请求后，服务端首先找到对应的组件描述文件，然后解析这个文件，生成服务器端UI树，并且渲染出Html端的组件树。Html代码最终被返回给浏览器，同时，在服务器端也建立了一个和浏览器端一一对应的组件树。
当浏览器端有事件产生的时候，事件发生的组件ID以及事件信息会被发送到服务器端，服务器端通过请求URL找到对应的组件树，以及发生事件的组件，调用这个组件的事件代码。组件事件代码中，会对组件树进行一系列逻辑操作，这些操作要被翻译成浏览器能理解的命令串。具体来说就是哪个组件ID，进行什么操作之类的。这些命令串被返回给浏览器端，最终解析执行，影响页面的展示。
整个流程说起来简单，但是做起来确实很麻烦。有兴趣的朋友可以去看一下JSF的几个开源实现。这里推荐大家去看一下ZK框架，这是我见过最完美的实现，当然，他并没有完全遵循JSF的标准。
事情就是这样，没有绝对的对与错。ZK虽然已经很完美，但是对他做一些定制扩展，还是不容易的。
我们回到这个事情的本身来看，前端和后端天然要有网络的传输，除非网速快到大家完全无感知，如果用户体验要求很高，我们总要做一些特殊的处理。
另外，前端和后端的工作确实各有侧重，前端更注重用户的体验，后端更关注性能、可用性、数据一致和安全等等。职业的分工是合理的，能够提升整体的效率和质量。
最后，回到业务本身，我们还是要根据自己的业务特点进行抉择。如果是后台业务系统，要求的是数据准确、功能好用，界面反而是次要的，那就可以采用这种事件驱动的框架。如果是服务大众的产品，用户体验至上，那还是建议前后端的分离，各自优化。
总结一下，BS架构设计也曾想追求事件驱动的开发模式，但是，有得就有失，我们需要自己去选择。
