samskivert / jmustache

A Java implementation of the Mustache templating language.
Other
834 stars 128 forks source link

Gracefully ignore placeholders if no match found instead of an exception. #113

Closed Halgaswatta closed 4 years ago

Halgaswatta commented 5 years ago

Probably, this will a specific case, just wondering about the behaviour, We have a requirement that only few placeholders have to be replaced, not all and I need to keep the file as it is with placeholders for those properties which is not resolved. Currently, it throws an exception if any placeholder is not present in the datamap. Is there any alternative for that?

Pasupathi-Rajamanickam commented 5 years ago

@Halgaswatta I used this to avoid exception? Is this something you're looking for? https://github.com/samskivert/jmustache#default-values

dagnelies commented 4 years ago

that would be great ...or even print an error like ??doesNotExist?? ...or nothing at all ...both are better than not rendering anything at all (as a default behavior).

PS: I guess it's no problem for those using the lib directly. However, it's not so straightforward on how to use/configure this "default value" when jmustache is used within a framework like Spring, where the whole rendering process is abstracted. Also, it is sometimes nice to see directly what value is actually missing.

Pasupathi-Rajamanickam commented 4 years ago

@dagnelies https://stackoverflow.com/a/32643079/2104638 ?? https://stackoverflow.com/a/42613870/2104638

dagnelies commented 4 years ago

The details first: what might work for spring boot 1. might not work for spring boot 2. and there might be other difficulties. But that is a detail and I think the suggested "hacks" should work in most cases.

The main point is rather what should be the default behavior?. And in that respect, it is IMHO much smoother to render an incomplete template rather than blow up with an exception.

Pasupathi-Rajamanickam commented 4 years ago

@dagnelies I might be wrong but here is my use-case. I really need exception and caught as 500. Let say I have a page that shows

Please follow the instructions carefully
{{instructions}}

In this case if somehow instruction missed we never know, but when it throws 500, I know I need to fix something at data level. Anyway lets wait for @samskivert to respond.

dagnelies commented 4 years ago

@Pasupathi-Rajamanickam Hi. Don't take me wrong either but I think your use case is rather the specific one.

I my case, and I think it is fairly common, you have complete UIs with menus, sidebars, content and lots of stuff, all filled with various mustaches. If it is a multilingual app, even each of your label might be a mustache! ...and if just one little tiny variable is missing, boom! The whole webpage is down with a big exception. Instead of a page with a missing piece somewhere, where you could still navigate and use, you just have a big exception.

Sure, there are workarounds, but I still think it should be the default to leave them empty.

samskivert commented 4 years ago

I'm certain that whatever the default is, someone will be unhappy with it. It is unfortunate that configuring mustache's behavior when using it via Spring Boot is more complex than if you were using it directly.

However, I am a strong believer in avoiding silent failure by default. If you have a use case where silent failure is acceptable, then it should be possible to make that work, and it is. But I don't think it should be the default behavior because it's far more likely that when failure is loud, a developer will notice that during development and configure their application appropriately. But if failure is silent, then it's much more likely that the developer will never notice, and the end user will see an error (a missing or placeholder element). The developer may never hear about it (just lose a customer instead), or hear about it via end user bug reports, neither of which are good.

One could also make the case that when JMustache is wrapped by Spring Boot or some other framework, they should make choices for the default configuration that make sense for that use case. So perhaps Spring Boot should configure JMustache with a default value, by default.

So apologies, but I'm going to stick with the current defaults.