Skip to content
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

Unable to turn off template Caching #417

Closed
kastork opened this issue Jul 13, 2016 · 3 comments · Fixed by #426
Closed

Unable to turn off template Caching #417

kastork opened this issue Jul 13, 2016 · 3 comments · Fixed by #426

Comments

@kastork
Copy link

kastork commented Jul 13, 2016

Version

  • vert.x core: 3.3.x
  • vert.x web: 3.3x

Context

This is a feature request in the area of developer experience.

The minimum cache size for templates (jade, handlebars, etc) is 1, and I haven't been able to find a way to turn the cache off completely.

The implication of this is that there is no way to get into a mode where you can simply edit a template and refresh the browser to see changes. You have to restart the vertx app every time you edit a template in order to see the changes.

k-mack pushed a commit to k-mack/vertx-web that referenced this issue Jul 30, 2016
TemplateEngine implementations perform caching based on whether or not a
system property is defined (see CachingTemplateEngine for property
name). Also, TemplateEngine implementations have isCachingEnabled() to
provide a read-only API view of this property for the TemplateEngine.
The `cache` field in CachingTemplateEngine is still initialized even if
caching is disable. This was kept to minimized future support for adding
a setCachingEnabled(boolean) to TemplateEngines to enable callers to
change the caching property during runtime and to avoid having to
re-initialized the `cache` field.
k-mack added a commit to k-mack/vertx-web that referenced this issue Jul 30, 2016
TemplateEngine implementations perform caching based on whether or not a
system property is defined (see CachingTemplateEngine for property
name). Also, TemplateEngine implementations have isCachingEnabled() to
provide a read-only API view of this property for the TemplateEngine.
The `cache` field in CachingTemplateEngine is still initialized even if
caching is disable. This was kept to minimized future support for adding
a setCachingEnabled(boolean) to TemplateEngines to enable callers to
change the caching property during runtime and to avoid having to
re-initialized the `cache` field.
k-mack added a commit to k-mack/vertx-web that referenced this issue Aug 3, 2016
TemplateEngine implementations perform caching based on whether or not a
system property is defined (see CachingTemplateEngine for property
name). Also, TemplateEngine implementations have isCachingEnabled() to
provide a read-only API view of this property for the TemplateEngine.
The `cache` field in CachingTemplateEngine is still initialized even if
caching is disable. This was kept to minimized future support for adding
a setCachingEnabled(boolean) to TemplateEngines to enable callers to
change the caching property during runtime and to avoid having to
re-initialized the `cache` field.
@jalkoby
Copy link

jalkoby commented Nov 1, 2016

👍

When do you plan to add it into vertx-web ?

@dimi2
Copy link

dimi2 commented Nov 9, 2016

I wanted this fix before the next release, so I tried to extend HandlebarsTemplateEngineImpl class...
The class is not designed for extension. It has private member variables (could be protected), nested final class 'Loader' without specific functionality for the template engine (could be extracted).
So the workaround was to copy the entire class source from the branch and adapt the fix over it.

It would be good to prefer extension-friendly implementation (for libraries in general) against heavy encapsulation.

@pmlopes
Copy link
Member

pmlopes commented Nov 9, 2016

There are a couple of issues here, vertx-web is doing cache as well the engines themselves do cache (some do, some don't) so if we're to work on this we need to decide to whom should be delegate caching (vertx or the engine) my gut feeling says vertx and then we can control the cache as desired by this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

4 participants