Enlive模板自动重新加载/检测基座服务中的更改

Question

我使用的是autoreload-server示例，它非常适合使用ns-tracker重新加载.clj文件的名称空间。

https://github.com/pedestal/samples/blob/master/auto-reload-server/dev/dev.clj

但是，它不会在resources/public目录中获取对enlive模板的更改。我已经将我的模板路径添加到defn watch中的向量中：

`([] (watch ["src" "resources" "resources/public" "public"]))`

在使用enlive deftemplate的命名空间中也是如此：

(net.cgrand.reload/auto-reload *ns*)

然而，这并不起作用。我的假设是ns-tracker仅适用于clj文件，并且我错误地使用了enlive重新加载功能。

有没有人在使用enlive并解决了这个问题，或者有什么想法可以尝试一下？

Answer 1

我希望this commit在2013年12月初的1.1.5版本中解决了Enlive Issue #6: Auto-reloading of templates。但是，在我的测试中，我不能确认这是一个修复。我可能做错了什么。

注意:我认为您引用的示例可以追溯到pre-0.2.0 tooling changes for Pedestal。我可能错了，但我认为您最好遵循当前的文档，而不是示例文件。

Pedestal's 'hello world' service app的主要建议(可能会改变)是：

1. 使用ns-tracker确定要重新加载的命名空间。
2. 将:resource-paths ["config", "resources"]添加到project.clj，以便Enlive可以找到静态HTML资源。

这些步骤不足以导致对资源的更改触发重新加载，因为ns-tracker不会关注:resource-paths。以下是详细信息：

1. ns-tracker依赖于clojure.tools.namespace.find/find-clojure-sources-in-dir.
2. clojure.tools.namespace.find/find-clojure-sources-in-dir

仔细想想，您就会明白为什么ns-tracker不选择资源；它们不是Clojure名称空间。在我看来，这是一个连贯的设计决策，命名为ns-tracker。

尽管如此，从实际的角度来看，很明显，当资源发生变化时，我们确实希望重新加载。

现在，让我补充另一件事。从工具的角度来看，假设您在资源目录上设置了监视。即便如此，要以细粒度的方式识别哪些特定的Clojure名称空间将受到影响也不容易。一个资源可以被多个deftemplate用作Clojure命名空间。因此，一个资源更改可能会影响多个Clojure命名空间。指向资源的字符串甚至可能是动态构造的。因此，在一般情况下，找出要重新加载的命名空间的精确最小集合可能是不可能的。

尽管如此，只要资源发生变化，重新加载所有Clojure命名空间就应该是“简单”和安全的。

所以，总而言之，我自己还没有解决这个问题，但希望我上面解释的将有助于推动球向前发展。

Answer 2

我找不到现成的解决方案，所以我最终编写了一个小的环包装来完成这项工作，请参阅https://github.com/kolov/enlive-reload