-
Notifications
You must be signed in to change notification settings - Fork 580
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Leading slash in template names #1981
Comments
I am so confused. Why are you putting slashes in your template names? |
Going straight for the existential questions, tbqh I don't know. While looking into this issue I noticed I have a wild mix of both (with and without leading slash) in my current codebase, can't quite remember how it was in previous projects. But that's kinda my point, right now a leading slash works in most cases. Do we want to "fix" this by disallowing leading slashes? That could lead to major breakage for some people... |
Think i'm ok with not supporting slash chars in template names. |
Totally fine by me, I just opened this issue because you said something along the lines of "This shouldn't happen". Maybe we can find a nice spot for a notice or warning in the documentation so this information doesn't get buried in a closed issue? |
Steps to reproduce the behavior
Having a leading slash in template names (e.g.
$c->render(template => '/my/template')
) can lead to unexpected behavior.Mojo Lite with templates in the
DATA
section flat out won't find them:curl
-ing/a
:OTOH:
While this is only a minor issue, it gets weird when using a full-blown Mojolicious app with template variants:
Templates:
Instead of bailing on templates with leading slashes (like Mojo Lite), Mojolicious finds them just fine:
But things break when variants come into play:
Running this through the debugger, I found that the problem (in the latter case) seems to be here in
template_name
:$self->{templates}
doesn't have leading slashes, so the variant never gets used.I honestly don't know what the right answer is here, but I guess somewhat more consistent behavior would be good. No idea how we can achieve that without breaking existing code.
The text was updated successfully, but these errors were encountered: