{% include %} tag can't find file about luminus HOT 20 CLOSED

Selmer looks for templates in the resource path and when the templates are located in the src folder, the path should be relative to it. There shouldn't be any issues including templates, the path would be the same as the one used when extending them.

For example, if you created a new app using lein new luminus myapp and then created a snippet to be included at myapp/views/templates/snippet.html, then you would use {% include "myapp/views/templates/snippet.html" %} in another template to include it.

from luminus.

There was no particular rationale for putting templates in the src folder as opposed to the resources one. The latter actually makes more sense, and I just pushed out a new version of the template that sticks the templates under resources/templates.

from luminus.

So I just tried moving everything over to the resources directory, and it didn't solve my include problem.

It still finds the main template just fine, but the included template (also in the resources/templates directory) still produces the following error:

java.io.FileNotFoundException
C:\devel\Eclipse\workspace\cfweb\resources\templates (Access is denied)

from luminus.

The line I am including it with is:

from luminus.

{% include "templates/include.html" %}

from luminus.

This seems to be related to another issue that was opened recently. It appears to be a windows specific problem, as I'm not able to reproduce it on OS X or Linux. I don't have a windows box handy unfortunately, would you mind investigating further why the (Access is denied) error occurs?

from luminus.

Yes, I'm on Windows. What investigation steps would you like me to take?

I think the interesting thing here is that it has no problem finding the main template, only the included template. I think it would be useful to understand how the process of bringing in an included template differs from bringing in the initial one.

from luminus.

The included templates are referenced by Selmer relative to the resource path. The relevant code can be found here.

Basically, the resource is read from the context class loader and for whatever reason this results in the access denied error on windows. It's possible that this is a windows specific permissions setting.

from luminus.

I figured out the problem:

(defn split-include-tag [^String tag-str]
  (let [sep (if (= java.io.File/separator "\\") "\\\\" java.io.File/separator)]
    (seq (.split ^String (get-tag-params (re-pattern (str "[^" sep "]include")) tag-str) " "))))

This code says that if you are on an operating system that uses \ as the separator, inclusion paths are only split with . But within Clojure it is typical to express file paths with "/" (and I'm going to be uploading this code to a linux cloud, so it needs to be cross-platform anyways). So I used:

{% include "templates/include.html" %}

to include the template, but on the Windows box, this doesn't chop up the path correctly.

I've confirmed that if I change the line to:

{% include "templates\include.html" %}

it works on Windows, but like I said, this won't be cross-platform.

I suggest processing the include filename the same way other resources are processed.

from luminus.

Ah perfect, I'll update the function to handle the separators in cross-platform fashion.

from luminus.

Although, now I recall that the reason split-include-tag checks for the File/separator is due to this issue.

from luminus.

Well, I'm in agreement with the poster on that thread that even though I'm on Windows, when working from Clojure, I typically express all file paths with / rather than .

Whatever you are doing with the main templates works fine for me.

from luminus.

Found a recommendation on stack overflow to handle it this way:

fileName = fileName.replace("\\", "/");
String[] splittedFileName = fileName.split("/"));

Another comment said that java.util.File tends to have pretty robust handling of both separators.

from luminus.

The reason that the additional logic is required when including the template is for splitting the tag elements correctly. This isn't necessary when reading the main template however.

The problem here isn't with actually reading the path, but with the fact that a windows user can specify the path using both \ and /.

from luminus.

A simple fix might be to simply check if the tag contains any \ characters in addition to checking the system file separator character:

(defn split-include-tag [^String tag-str]
  (let [sep (if (and (= java.io.File/separator "\\")
                     (.contains tag-str "\\")) "\\\\" java.io.File/separator)]
    (seq (.split ^String (get-tag-params (re-pattern (str "[^" sep "]include")) tag-str) " "))))

from luminus.

Alternatively, I could replace all "" with "/", which would be preferable:

(defn split-include-tag [^String tag-str]
  (seq (.split ^String (get-tag-params #"[^/]include" (.replace tag-str "\\" "/")) " ")))

I just checked in the above change into Selmer, could try and see if it works with both "/" and "" separators. If so, then I could push out a new version with the fix.

from luminus.

That works.

from luminus.

Great, I pushed out new versions of selmer and luminus, so hopefully everything works as expected now.

from luminus.

@Engelberg are we ok to close this one?

from luminus.

Thanks.

from luminus.