Fixed extension to ignore common jinja extensions

[vallentin]

Fixes #457

• Fixed so extension() for foo.html.{jinja,jinja2,j2} resolves to html instead of {jinja,jinja2,j2}.
• Changed to allow both path and ext, i.e. so it would allow #[template(path = "template.foo.bar.baz", ext = "html")]

This was just a quick fix, so I hope I didn't overlook anything

[djc]

I'd like to split the first commit into a change that separates out the abstraction logic and a separate commit that adds the Jinja extension consideration. It'd be nice to have some tests for the new version of that function, too; maybe that would be easier if it was a free function rather than a method?

[vallentin]

Just to be clear, so first commit is just fn extension() where it just returns self.path.extension(). The second commit is then changing it, to account for .jinja, etc.

Good idea with the tests. I can add a private function fn extension(&Path) in input.rs, and then test that function. Is that fine?

[djc]

I would incorporate the to_str() part in the extracted function immediately, which seems to match the intended contract anyway.

Private function to enable testing makes sense.

[vallentin]

Unsure if I'm misinterpreting or miscommunicated. But what I meant was, the first commit would just be:

pub fn extension(&self) -> Option<&str> {
    self.path.extension().map(|s| s.to_str().unwrap())
}

Then the second commit adds the .jinja check. That's how you wanted it split, right? :)

[djc]

Yup!

[vallentin]

@djc fixed it

Also added some extension tests for #[template(path = "...")] and #[template(path = "...", ext = "...")]

Edit: Weird, GitHub is showing the commits in the wrong order
Edit 2: aaand, now they're shown in the correct order

[djc]

Great, thanks!