尝试全栈(中)

上回书说到,只要把页面模板里的文档 ID 正确传入,即可完成单篇 PDF 导出的功能流转。如此一来,就需要搞清楚这个 ID 可以从哪里得到。

最自然的想法是,页面生成的时候,把 ID 直接写入到菜单项的链接 URL 里即可。即在 <li><a href=”{{urlfor “DocumentController.ExportDoc” “:key” .Model.Identify “:id” “” “output” “pdf”}}” target=”_blank”>文档导出为 PDF</a> </li> 中进行正确的填充。既然 :key 的对应值可以使用 .Model.Identify 表示,那是不是会有个 .Model.Id 之类的可以直接使用?实验以失败告终,说定义的变量不认识……

这下激起兴趣,想知道原本的 .Model.Identify 这样的变量是如何工作的。于是在源代码里搜寻,在 controllers/document.go 的 Read() 函数中发现了 c.Data[“Model”] = bookResult 这样的语句,恍然大悟,于是兴冲冲地寻找 bookResult 的数据结构定义,想看一眼 Identify 之外是不是还有 Id 这样的信息,再次失望。只好退而求其次,自己来输出了:c.Data[“DecumentId”] = id,此处的 id 是既有代码逻辑里已经获取到了的。相应地,上面的语句也更新为 <li><a href=”{{urlfor “DocumentController.ExportDoc” “:key” .Model.Identify “:id” .DocumentId “output” “pdf”}}” target=”_blank”>文档导出为 PDF</a> </li>。测试,发现了两个问题。一是这个 ID 的值是 0,这并不是个有效的文档 ID,二是这个 ID 在切换文档时并不会随之而更改。后一个问题显然比前一个还要严重,这意味着机制的失败,所以决定优先处理。

加入一些调试输出的代码,证实 Read() 方法在绝大部分情况下会被前端的文档查看请求触发(未被触发的情况后文再谈),但是,其中不少请求是以 Ajax 的方式发起的,它所请求的内容返回到客户端之后,并不会用于更新上文链接所在的区域。这的情况说明,导出单篇 PDF 的请求链接已经不可能由后端程序一次性写定,而是需要前端用 Javascript 代码进行胶合处理。也就是说,点击链接需要触发一个脚本处理器,在其中根据当前文档现场拼装目标 URL,然后提交请求到后端。

找来了公司的前端专家进行指导,终于学会了把 A 元素用 onclick 事件和脚本对接起来。现在聚焦了,在脚本里如何探测当前正在呈现的文档的 ID 呢?如果当初文档在后端生成的时候,把 ID 写到了某个地方就好了,当然,Ajax 更新文档显示的区域时,这个 ID 也要能跟着更新才对。找了一圈,并没有发现如此趁手的现成物料。

前端专家怒了,说直接用浏览器地址栏里的 URL 吧,反正 RESTful 风格的,也好解析。随随便便用 / 字符 split 了一下(其实还 reverse 了一下),就把 bookid 和 docid 给分离出来了。随手测试,果然好使,不但 ID 确实获取无误,而且还同时验证了老夫后端 Go 语言的代码重构是一把奏效,单篇文档的 PDF 文件顺利诞生!

尽管如此,不过似乎还是有些地方处理得不够好,咱们下回再说。

发表评论

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