Extending mustache.java

[Martin]

Hi,

first of all mustache.java is very interesting templating solution. Good job!

However sometimes it's quite difficult to extend it. One example could be the DefaultMustacheFactory. A lot of internal classes use DefaultMustacheFactory instead of MustacheFactory interface (e.g. ValueCode, IterableCode, DefaultMustacheVisitor, ...). In the end you're forced to extend DefaultMustacheFactory which is not that easy as for example MustacheParser constructor is protected and not usable outside com.github.mustachejava package. It would be nice to make extending easier...

PS. My use case involved loading templates from file system and refreshing cache on demand (very usable in debug mode).

Martin

[Sam Pullara]

You should be able to do both of those things by extending the
DefaultMustacheFactory and overriding a couple of methods. In this
case getReader() and compile(). You're right though, there is some
coupling between the default implementations. If you have a specific
thing you'd like to do I'd be happy to make it possible to do it
assuming that it isn't possible already.

Sam

[Martin]

Well, I managed to extend DefaultMustacheFactory and implement all I needed but it was a little bit tricky. Overriding getReader method was not a problem. To enable the refresh functionality I had to override compile(String name) method, have own mustacheCache and also extend MustacheParser and place it in the same package where my extened MustacheFactory resides (as I wrote MustacheParser constructor is protected).

I think it would be great to allow the extending factory to provide its own Guava CacheBuilder (expiration, maximum size, etc.)... Maybe some protected method like this:
protected CacheBuilder provideCacheBuilder() {
 // return defaults
}

And also make mustacheCache attribute protected so that extending factory could manage the cache (invalidating entries, etc.).

Thanks Sam

Martin

Dne úterý, 7. srpna 2012 22:55:39 UTC+2 Sam napsal(a):

[Sam Pullara]

I think it makes a lot of sense to make the cache accessible. I'll look at that today. Thanks for the feedback. 

Sam

Any errors are bugs in iOS 6

[Sam]

Some refactoring of this has gone into master. I'm going to do a release soon so it would be great if you can check it out.

Sam

[mtrovo]

I think all this caching should be made available only on a decorator factory.

Like:
MustacheFactory
CachedDefaultMustacheFactory extends MustacheFactory

DefaultMustacheFactory implements MustacheFactory
DefaultCachedMustacheFactory extends DefaultMustacheFactory implements CachedDefaultMustacheFactory

For some applications (handlebar for example) there is no need for a cache on the filename level (handlebar would only be useful with a sort of filename + timestamp key) and some applications (mainly for development phase or no-cache like policies)  would like to never cache. Today the only way to ignore this cache mechanism is to create a new instance of MustacheFactory everytime.

[Sam Pullara]

Pretty reasonable. I will take a look at doing something along those
lines. Might not be named the same thing but it makes sense to have an
uncached one in the hierarchy and easily available.

Thanks,
Sam

[Martin]

Sam: seems good to me. I did some smoke tests and it's working ;-)

+1 for uncached mustache factory version.

Martin

Dne úterý, 28. srpna 2012 4:05:51 UTC+2 Sam napsal(a):