我大概明白怎么用了,简单概括如下
一个bags必须要有一个recipe,不然这个bags无法形成域名,也就无法编辑
一个recipe可以有多个bags,但至少有一个,不然无法构建
recipe中的bags有优先级。同样的标题条目,优先级高的被recipe使用,低的无效。
这样带来的一个好处是,你可以自己做一个定制化的wiki模板,然后维护这个模板
接着你在你的其他生产环境中使用这个模板,但有些功能你当前的生产环境你不需要,所以你可以直接修改你当前生产环境的内容,不会影响到你的bags条目
另一个更常见的好处是,当你更新你的模板时,其他使用该模板的recipe会直接更新,这样就不需要一直调整了
目前存在的问题
文档上说会跟用.tid展示内容不冲突,但没有具体说明如何处理
因为显示可以与git相结合
目前recipe和bag没有删除选项,可能是还没有做
目前插件也作为bags提供,这个方案有点不那么好。因为插件太多了,会有很多个bags。如果把CPL收录的插件提供过去,那有好几百个。上百个bags显示的就很糟糕了。
怎么与筛选器结合,这一点还没有说。目前来看,bags与筛选器无关,出现重名的条目,就按优秀级来处理。
可以期待实现的
个人知识库管理会更加高效
举例来说,我可以只在一个book-info的bags中更新书籍信息,而其他的什么都不管,当我需要查询书籍的信息时,我可以在book-info中查找,也可以直接在我的主知识库中查找。
以及上述实现的模板功能。我可以有一个template,里面包含了大量我自定义的功能,但没有打包成插件。而且这里可以是一个生产环境,我可以直接在这里测试。但有个可以预见的问题是,测试条目也会随之附带到main中,所以需要通过筛选器来结合处理。
减轻性能。虽然我不知道具体是怎么处理的,但可以预见的好处是,性能会得到极大的改善。当然这个可能需要测试。
多用户处理
比如论坛上很多个不同的wiki,估计就可以使用这种方式来处理展示了,但背后又涉及到git方面的内容,估计还是不行
可能需要服务器,这个有点麻烦。因为文档中举了一个老师的例子,老师可以把他的教学资料放在一个bags中,而学生可以每个人都有一个自己的bags,可以提交作业。然后老师查看且修改。理论上都没有问题,最大的问题在于,是老师去部署这个服务器还是学校,学校真的会这样做吗?
这个肯定是学校部署的,老师估计是类似跟用学习通一样。算了,这方面还是不过多讨论了。
感觉等技术成熟了,太记应该可以把这个放进去,从而构建更强大的TiddlyWiki。