尝试全栈(下)

前面的经过,看起来问题是解决了,但是从一个开发老鸟的角度来说,其实最终的方案并不那么专业和优雅。

经验告诉我们,URL 经常是靠不住的。这不,刚做了几下小测试,就发现 URL 有时候呈现出意料之外的形态。例如,如果从搜索的结果列表中选择文档打开,则 URL 中就会出现双斜杠的情况,前端专家听到这个消息的时候依然保持了简单粗暴的风格:要不咱们把重复的斜杠合并去掉?擦,问题是并不知道会出现多少种特殊情况好嘛……

其实当初在 default_read.tpl 里的最下面添加 Javascript 函数的时候,就已经注意到上面的函数,貌似是要给文档目录树里的节点添加点击响应处理,心想这是个更新 docid 的好地方。把代码写进入,竟然切换文档时并不触发执行,相当沮丧。仔细一看,原来这个事件处理并不是安装到文档目录树的节点上的,而是安装到搜索列表的节点上的。

那怎么才能让文档目录树的节点也增加一个类似的处理器呢?没成想,没找到给节点增加点击事件处理的合适地方,意外发现了个文档加载结束的事件(在 static/js/kancloud.js 中),名为 article.open。这个事件简直比点击事件强太多了,因为后者还要自己去想办法获取 docid,而 article.open 事件自身的参数里就有 docid,于是,结合页面生成时对 DocumentId 的初始化,以下代码完美解决了 docid 的更新问题:

事实上,上面的代码还是略有犯懒,因为当一个 book 被打开时,左侧并没有选中的 doc,此时的激活文档 ID 其实是 0,此时如果选择导出单页 doc,最自然的处理方式应该是等效于导出整个 book。当然,这个修改很简单,随便谁都可以完成。

更新:作为一个强迫症还是没忍住,把 0 号文档输出的代码给完成了,同时还把 URL 路由从 ExportBook 和 ExportDoc 分开又进行了合并,毕竟后面有没有文档 ID 就足以区分导出的对象是 book 还是 doc 了。

 

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注