Is it safe to reuse the DefaultMustacheFactory?

[Florin T.PATRASCU]

Hi there,

I am developing an extension to offer the Mustache rendering support to my simple web framework (Micro) and I wonder if it safe to reuse the DefaultMustacheFactory for compiling the templates?

You can view the code on Github at: https://github.com/florinpatrascu/micro-extensions/blob/master/mustache/src/ca/simplegames/micro/viewers/mustache/MustacheViewRenderer.java#L53, if need be.

Thank you for creating this library and for the user support,

-florin

[Michael Hixson]

Hi Florin,

Yes, it's safe to reuse a DefaultMustacheFactory. The only difference
between reusing one and using a freshly created one is that a
DefaultMustacheFactory caches the templates it's already compiled,
assuming you compiled them using the "compile(name)" method.

In the projects where I've used Mustache I have a helper method to
provide a MustacheFactory. In production it provides the same
instance every time. In development it provides a fresh instance
every time, because I want to be able to alter the template and see
the changes without restarting the application.

It looks like you're manually caching the compiled templates. This is
probably necessary because you're using the "compile(reader, name)"
method instead of the "compile(name)" one. If you could somehow
rework it to use the single parameter version instead you could get
rid of all that custom caching in your code, I believe. Is there a
reason such a refactoring is not possible?

-Michael

> --
> You received this message because you are subscribed to the Google Groups
> "mustache.java" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mustachejava...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Fred Janon]

Use in servlets: I suppose then that I can create the DefaultMustacheFactory and compile all my templates in the Servlet.init() and just call mustache.execute(writer, data) in the get/post servlet method? All of this would be thread safe?

Thanks

Fred

[Florin T.PATRASCU]

Thank you for your reply, Michael.

> Is there a  reason such a refactoring is not possible? 

Not at all, I'll do that and return for feedback, if you don't mind?!

In my case, the repository (which is also the manager of the resources -files, etc) is responsible for deciding if the resources are cached or not. The "cacheability" attribute of a resource being decided by an environment variable that, similarly to Rack/Rails/etc, tells µ what type of instance is it in; production, development, test. My goal being to only cache the templates if µ runs in 'production' mode. And I thought would be cheaper to cache the compiled templates and hitting a cache I can manage (through µ's own cache manager and admin tools), instead of delegating the cache responsibility to the Mustache framework itself. Most probably a consequence of my insufficient knowledge about Mustache's core design.

I also spotted a bug, now that I reviewed my own code. The second param in my compile method is the template encoding, instead of the template name :( A lesson I shouldn't test/commit late in the night :)

Thank you so much for your feedback,

-florin 

[Florin T.PATRASCU]

Fred - I am not a Mustache expert, but I believe the execute(..) is thread safe, provided your "data" *is* managed in a thread safe mode, which I am sure you're taking care of.  See this test: https://github.com/spullara/mustache.java/blob/master/compiler/src/test/java/com/github/mustachejava/ConcurrencyTest.java,  maybe it helps.

My 0.2CAD

- florin

[Florin T.PATRASCU]

Michael - re: refactoring the cache support;

On a second thought, after understanding the implementation of com.github.mustachejava.DefaultMustacheFactory#getReader and com.github.mustachejava.MustacheParser#compile, I'd prefer to let my Repository decide about loading and cacheing the resource. It is less overhead because I already have the template content when I am asking Mustache to compile/execute it, and passing a StringReader it's cheaper than letting Mustache to find and load the file, I am thinking. I almost burned myself when I had a similar issue with the ResourceLoader implementation from Velocity, so I'd like to prevent a similar experience.

I also have to say I am a bit puzzled by the "file" parameter role in this implementation: com.github.mustachejava.MustacheParser#compile, but this is an off-topic already :) I should definitely spend more time reading and understanding the Mustache implementation. It's a very cool project.

Thanks again!

-florin

> You received this message because you are subscribed to a topic in the Google Groups "mustache.java" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/mustachejava/lkqv0QYnUxo/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to mustachejava...@googlegroups.com.

[Sam Pullara]

The file parameter is just a name for debugging. I should probably
figure out a better way to do that...

Sam

All my photos are panoramas.

On Mar 22, 2013, at 9:52 AM, "Florin T.PATRASCU"

[Florin T.PATRASCU]

Thank you for the clarification, Sam.

-florin