话说被分配一个任务,把旧版文档目录迁移到新版。用到一些思路,记录一下。

旧版目录结构数据源在MYSQL, 作为懒人,尽量回避mysql connect,所以就直接用js搞吧。

打开旧版本的后台,看了一下dom 结构,把数据先抽出来。

2013-12-27_115253

由于页数不多,手动翻翻页面,把数据保存一下就好。

把上面的数据保存成一个大数组,接着去重,以及换成_id:value_的形式。

得到数据如下:

新的规范中,新目录结构如下:

2013-12-27_120439

我们看到,四级目录,其中三级目录开始,容量是两位数,所以要考虑ID容纳空间的问题。

这里可以考虑半手动的方式,就是把目录按照结构输入到一个wordpress分类中,然后在模版中写一句话,把结构打出来。

外面添加一个容器,一会方便用js来搞成和上面一样的数据结构。 打开wordpress的页面,把这里的结构搞出来。

2013-12-27_120848

因为只有四级,结构也比较死,直接写成固定的代码,拿出来数据就可以了,没必要过度浪费时间写递归。 我们继续得到新的数据。

ID的长度为9位,如果以后要扩容也毫无压力,当然这里排除了以后目录存在上百个的情况,因为运营的童鞋和产品的童鞋不会允许文档过长的。 这里发现第一组数据中的value是包含空格的,编辑器或者脚本中搜索"\s",正则批量替换掉。 接着开始记录关联性数据了,这里比较笨,用循环的方式。

console里回车一下,应该一瞬间就跑出结果了,然后把没有对应关系的分类手动补全一下就完事了。

至此,记录写完,大概用到的方法有:

  1. 利用第三方库文件将数据从DOM中剥离,抽象成数组结构。
  2. 目录设计预留容纳空间。
  3. 递归匹配,使用序列化的对象格式来继续处理数据。

如果你有类似需求并且数据量大的话,上面的可以优化的事情有这些:

  1. 手动合并数据改成自动合并,数据存储local storage或者indexed db。
  2. 手动请求分页改成ajax请求并解析新document中的对应dom。
  3. 最后一段处理,写匹配规则。

–EOF–