- oa-codeblock项目架构设计 - 基本构建
问题 公司使用泛微的Ecology 9作为OA系统，OA提供了代码块功能，能让我们在页面中嵌入自定义的HTML、CSS和JavaScript代码，实现自定义功能。 目前看到同事的开发模式：在后台管理中打开代码块编辑界面，编写代码（主要是JS代码和CSS代码），保存，然后刷新页面查看效果。如果需要修改，就再打开编辑界面，编写，保存，刷新。如此往复。 这种模式显然非常繁琐，除了要编写代码，还要在后台管理中做很多步骤。通常代码要改很多次才能写好，因此这种模式的效率非常低。 我决定做一个开发框架，命名为oa-codeblock项目，简化整个开发流程，提高效率。 思路 代码块中不直接写JS和CSS代码，而是只引用JS脚本文件<script src="...">，CSS代码包含在脚本文件中，也就是说，最终一个脚本文件就对应一块功能，其中同时封装了行为和样式。 开发时，引用的脚本文件在本地，可直接修改其中的代码，然后刷新页面查看效果即可，不必重复保存代码块，也就是说，开发流程被简化为“编写→刷新”2步即可。 部署时，将脚本文件上传到服务器，然后将引用的脚本文件地址改为服务器即可。 实现 基于Node.js来实现开发框架，使用NPM管理依赖。 项目目录结构： package.json：NPM配置文件。 index.js：框架核心代码，执行构建。 template.js：用于构建脚本文件的模板。 src/：源文件目录，存放业务代码。 流程布局/：存放用于流程布局代码块的业务代码。 功能名称/：存放指定功能的业务代码。 script.js：业务代码的JS部分。 style.css：业务代码的CSS部分。 建模布局/：存放用于建模布局代码块的业务代码。 ... 建模查询/：存放用于建模查询代码块的业务代码。 ... dist/：构建输出目录，Git忽略。 脚本文件模板template.js：用于构建脚本文件成品的模板，其中写好了在documentready时才执行JS代码，以及将CSS代码应用到<head>中，并留有占位符，以便将具体的JS和CSS代码替换进来。 框架核心代码index.js： 构建过程：遍历src/目录，如果发现某个目录中有script.js，则说明该目录要构建成一个脚本文件，并输出到dist/目录，src/A/B/C/script.js将输出到dist/A/B/C.js。构建时，从script.js读取JS代码，从style.css读取CSS代码，替换template.js中的占位符，然后输出。 持续构建：支持命令行参数指定一次性构建或持续构建。持续构建时，监听扫描到的script.js和style.css的变化，并在有变化时重新构建对应的脚本文件。这样，“编写”和“刷新”之间就无需手动的“构建”步骤。 实践表明，本开发框架显著提高了开发效率。
- 微信读书转PDF
微信读书上有一些书，我想用iPad做手写笔记，但网上找不到现成的PDF文件，因此自己想办法将其转为PDF。 在电脑中下载安装逍遥安卓模拟器，设置屏幕分辨率。 参考数据：1536×2048（宽高比3:4，分辨率同iPad），300dpi。 在安卓模拟器上安装微信读书app。 在微信读书中将需要的图书添加到书架，然后选择下载到本地（避免临时加载页面内容）。 打开图书，设置图书内容页面显示效果。 在模拟器中录制操作宏： 向左滑屏（切换到下一页）。 截屏。 批量执行该操作宏，得到一批屏幕截图文件（72ppi，不适合直接转成PDF，PDF页面尺寸会太大）。 用Photoshop打开一个截图文件，录制动作： 设置图像分辨率，宽高不变，“分辨率”改为300像素/英寸。 保存文件。 关闭文件。 在Photoshop中对所有截图文件批量执行此动作。 使用Acrobat、福昕PDF编辑器等PDF编辑软件将截图文件合并成单个PDF文件。 如果有需要，可对PDF执行OCR，使页面文字可用。
- 植入式Web前端开发方法
上一篇，我对植入式Web前端开发的基本情况做了描述，本篇就来探究其开发方法。以下假定CMS只能植入前端代码，并且需求规模是任意大小的。 代码形式 HTML代码是直接植入的毫无疑问，但除非植入的代码非常简短、功能独立，且植入点数量不多，否则将CSS和JavaScript代码直接嵌入在HTML代码中是不明智的（有的CMS可直接植入CSS和JavaScript代码，其本质也是将这些代码直接嵌入在HTML中），主要有以下弊端： 降低性能：CSS和JavaScript代码不会被浏览器缓存。 不方便调试：每次代码修改都要重新提交到系统中；代码量比较大时，混杂在一起难以书写。 不方便管理：植入点比较多时，尤其是有公共代码时，难以清晰地管理。 更好的办法是，将CSS和JavaScript做成单独的文件，在植入的HTML代码中通过<link rel="stylesheet">和<script>标签引用之。 通常，CMS会提供资源文件上传的功能。可以先在本地开发好CSS和JavaScript文件，再上传到CMS中，然后使用上传后CMS提供的文件URL。如果CMS不提供这种功能，也有其他各种办法，只要使得CSS和JavaScript文件能被公网访问即可。 开发环境 通常，在CMS上提交代码是立即生效的，所以不能直接在用户使用的页面（即生产页面）上一点点地开发和提交。一个可行的办法是，专门设立一个用户不会访问的、仅供开发用的页面，在此页面上开发，待代码稳定之后，再提交到生产页面上。 通常，开发时HTML代码部分是改动比较少的，更频繁改动的是CSS和JavaScript代码。在使用独立文件时，必须保证页面引用的CSS和JavaScript文件始终是最新的。如果它们在远程主机上，这种保证比较麻烦，一般要频繁上传文件。更好的办法是，在本地建立一个Web服务器来提供这些CSS和JavaScript文件。 在本地机器上建立一个Web服务器，让正在开发的CSS和JavaScript文件能够通过这个服务器访问到。然后在开发页面的植入代码中引用本地服务器上URL（可以在URL末尾加一个?，让浏览器不缓存）。这样，只需要刷新一下页面，无需重新提交，最新的CSS和JavaScript代码就立即生效了。 当代码稳定时，再将文件一次性上传到生产环境中，然后修改HTML中的引用的URL为生产环境中的URL（末尾无?），提交到生产页面即可。 在HTML代码不需要修改的情况下，甚至可以直接在生产页面上做开发。 在hosts中将生产环境提供CSS和JavaScript文件的主机域名指向到本机，然后在本地Web服务器中绑定该域名，并使得文件的访问路径与生产环境完全一致，最好再设置CSS和JavaScript文件不缓存。如果是HTTPS访问，则还需要做一个自签名证书，并在浏览器中忽略证书问题继续访问。如此，在本机，生产页面中获取文件时实际上会从本地获取，而用户的访问仍然正常基于生产环境。 更多 到这里，已经可以看到，除了代码部署方式有些特殊，其他方面实际上跟正常的前端开发没什么区别。因此，各种前端开发技术、工具实际上都可以使用，如多文件开发然后编译成单文件、代码压缩、Git版本控制等等。 如果规模比较大，还可以专门开发一个自动部署机制来做植入代码的持续集成。
- 植入式Web前端开发
在博客园、凡科建站和其他一些CMS系统中，提供了允许管理者在网页中插入自定义HTML代码的功能，我将其称之为“植入式”的Web前端代码。管理者不能修改系统本身的代码，但通过这种方式，也可以实现一些自定义功能，即二次开发。 因为CSS和JavaScript可以通过嵌入或外部文件的形式写在HTML中，所以允许植入自定义的HTML代码，其实就是允许使用任何前端资源，在结构层（HTML）、表现层（CSS）和行为层（JS）上都获得了控制能力。不同系统对于植入代码，一般都会允许HTML和CSS，但不一定会允许JS（过滤掉<script>）。如果允许JS，则植入代码能做的事情范围会极大地扩展，因为JS是通用编程语言。 在允许植入并运行JS的情况下，几乎只要是在前端范畴内能做的事，就都可以实现。除了常见的在局部用JS优化页面原有功能、添加新功能之外，理论上，甚至完全可以把整个DOM树替换掉，换成与原页面内容完全不同的全新页面内容表现。比如现在这篇文章的页面，我完全可以通过植入代码，令其最后展现给读者的是一个Web游戏程序。 当然，这种模式也并非随心所欲，它也有着诸多限制，比如性能（原页面的所有资源仍然要加载）、SEO（原页面的HTML结构仍然都在）、兼容性（库冲突）等等，限制的主要原因在于，原页面代码始终都在，植入代码只能在页面载入一段时间之后才能开始起作用。植入代码只是对于前端，在某个范围内可以做到一些灵活性，获得一些控制权，对于后端，没有任何影响。 所以可见，本质上，植入代码的能力不过是正常的前端能力的子集，虽然它确实能在某个范畴内玩出花来，但除非真的必要，否则绝不会是首选方案——显然应该先考虑修改页面本身的代码。 因此，这种模式基本上仅用于在必要时，做页面局部的调整、优化或新增功能。比如凡科商城这种在线的CMS平台，管理员对系统本身的页面代码没有控制权，系统提供的常规定制选项又无法满足需求，那就必须通过这种手段来做二次开发了。 不过，虽然在服务端这种模式的应用有限，但在用户端这种模式却是应用广泛，这就是大名鼎鼎的油猴脚本。 继续阅读：植入式Web前端开发方法。
亚德雷