-
Notifications
You must be signed in to change notification settings - Fork 0
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
Caching should take filter settings into account. #4
Comments
I see you released a new version. Did you happen to think of a way to address the issue above? |
It's an interesting point. This goes somewhat against the intended purpose of the module. While external settings (that affect rendering) could be altered, after the template has been compiled and cached, that is not something the module was designed for. Should the template be recompiled if settings have been altered? I'll have to do some tests first and think about this. Thanks for pointing it out. |
After testing, I can confirm that serving cached files can break if settings that affect rendering are altered. This is however not an issue for two reasons:
I will add documentation to make it clear that settings should remain that same, and warn about the affect of changing settings once templates are cached. I have also added an error message if a filter is deleted and then used in a cached template. |
I stumbled upon this while playing around with Plate with regards to making auto_filter changes that were not being reflected in the corresponding compiled template. If you combine your Synopsis example and job/letter example, run it and then remove auto_filter and the html and trim filters entirely the serve call will die because trim is no longer defined. Another situation that doesn't die but also isn't correct is if you cache the template using the default auto_filter (don't include it in the object creation params) and then disable the auto_filter (include it and set to undef).
HTML::Template has specific scenarios were changing the object properties results in a unique cached version of the template. It creates a hash key based on the settings that change the compiled template and looks them up that way. Maybe it's only changes to auto_filter? So maybe it's as simple as prepending the auto_filter setting to the compiled template name?
The text was updated successfully, but these errors were encountered: