资源说明:
##更新说明 本文档撰写于2012年,所描述的是当年的状态。目前(2013年7月),兰亭fe已经使用新的架构重新实现了5个模板页面。随着本人的离职,这份文档将停止更新。 ##兰亭前端现存问题:## 1. **开发模式**:前后端耦合太紧,js,css内嵌在php(html)中,模块化程度有限,代码复用度不高。 2. **模板系统**:无法有效支持快速分支的并行开发模式;在线编辑器功能太弱,缺乏全文查找和语法校验等基本功能。 3. **重复工作**:模板部分在前后端重复模块化2次;模板系统提供了widget,后端又重新封装一遍。 4. **源码版本控制**:模板系统中前端静态资源没有版本控制;前后端共用一个svn仓库导致文件数量膨胀,源码分支合并回滚等操作不方便;svn仓库中js和css源码是压缩版,但压缩比率较低。 5. **发布流程**:前后端代码一起上线,不利于快速发布,不利于快速hotfix。 ##兰亭前端模块化架构设计目标:## 1. **前后端分离**:前端源码独立控制,消除页面内嵌js,css。 2. **模块化**:js,css,html均模块化,提高代码复用度。清晰的依赖关系管理,使修改更安全,扩展更容易。 3. **模板复用**:前端提供模板,后端只提供渲染模板需要的数据及接口。模板和数据是严格分离的。 4. **并行开发**:前后端可并行开发,后端只关心提供数据及接口服务。多项目可并行开发,可快速分支开发。 5. **独立发布**:前端代码(js,css,img)可独立发布上线(快速发布,频繁发布),加快功能迭代和hotfix速度。 6. **提高性能**:消除大部分页面内嵌js和css,提高静态资源缓存利用率和浏览器解析渲染html的性能。 ###合理的架构可以让新手快速成长,独当一面;对多项目多任务可快速响应### ##设计规划## 部分文档根据内部lightsource工程做调整。 1. **JS模块化**: 1. 组件使用jQuery(or zepto)插件方式来组织代码; 2. 使用`require('a/b/c.js');`方式引用依赖模块;上线前由构建工具合并压缩成单个文件; 3. js在页脚加载,故所有业务代码都应在加载后立即执行,部分特殊代码在`dom ready`后执行。 4. js代码中如果涉及到大段html字符串拼接,要使用mustache.js模板来替换之,保证代码的结构化和可读性。 5. 页面全局配置变量只有一个:`litb`。由后端打印出前端需要的通用信息。 6. 所有业务逻辑在$.sandbox(即try catch)中执行,以隔离模块错误。 7. 使用(jQuery) **自定义事件** 在组件之间交换信息。发布的主题以`widget-xxx-topic` 形式,数据统一为单个Object类型变量. `on(bind)`和`trigger`的主体均为全局window,即$(window); **如果不是全局广播,应该在特定dom节点上监听及触发自定义事件** 触发事件时只提供一个 Object 类型数据; 1. **bind** custom event: ``` $(window).on('widget-custom-event-name', function(event, data) { console.log(event, data); }); ``` 2. **trigger** custom event: ``` $(window).trigger('widget-custom-event-name',{'a' : 1, 'b' : 'str','list':[1,2,3]}); ``` 3. **unbind** custom event: ``` $(window).off('widget-custom-event-name',[handler]); ``` 2. **CSS模块化**: 1. 统一使用less来开发基础组件和业务代码,使用`@import-once 'a/b/c.less';`方式来引用依赖(注意要使用 **@import-once** 保证只引入一次);上线前由构建工具合并压缩成单个文件。 2. 统一的namespace管理,每个widget的最外层容器附加`class="widget widget-name"`,内部css均在`.widget-name`选择器内定义组件样式。less支持class嵌套,可以提高代码可读性。 3. 最大程度上集成,复用bootstrap这个css框架; **按需引用** 其组件.less源码(注意,bootstrap单个组件均依赖 **variables.less** 和 **mixins.less** 这2个基础文件,需要和特定组件一起引入)。 3. **HTML模块化**:采用无逻辑模板引擎 [Mustache](http://mustache.github.com/) 来组装html,强制隔离view和代码逻辑。 1. 前端提供模板;后端只负责提供数据和数据接口。 2. 为避免修改同步,原则上不允许后端开发人员修改前端模板。 3. Page:单个页面,引用多个pagelet。 4. Pagelet:单个业务逻辑相关模块(较独立的视图区块),引用多个widget。 5. widget:业务无关的独立html片段。 6. 同一widget被多次引用时需要提供不同上下文环境的数据. 7. js和css引用: 1. page模板中可引用自身对应的一个js和1个css,分别引入依赖的js和css,负责模块组装和模块通信逻辑。 2. pagelet和widget模板文件中不直接引用对应的js和css,在测试期由测试工具自动引入其依赖的js,css。 8. 每个widget组件容器DOM都要包含一个`class="widget widget-name"` 9. 注意mustache对html的转义,要避免xss攻击,也要避免2次转义造成乱码(因部分老接口在入库时已经转义了一次,渲染时应该使用`{{{}}}`输出)。 10. **模板数据**: 1. 与html模板文件同名的json文件用于提供模板测试数据(_test/main.json, 其他_test/*.json 可在线切换,以测试不同模板数据测试效果)。 2. 模板同名文件中I18N这个数据项(HashMap)提供测试国际化数据,可测试模板国际化效果。 3. **js脚本需要的数据** : 有两种方式来获取。 1. 通过ajax请求向服务端按需动态获取 2. 附加在主模板json数据中,通过模板html的自定义属性,如`