My general opinion on this sort of thing is there are lots of libraries and tools around in the Java world for doing string manipulations and such, they don't need to be built into a template language. Taking that one step further, I'd actually prefer that the expression syntax in the template language makes it easy to call an existing API vs trying to make everything built into the template language.
For example in addition to using FTL I also use Groovy heavily and Groovy already has a great API including standard Java API augmentation for all sorts of things. Yes, FTL could use the Groovy String and other expanded objects as a reference for built in design and have a good set of commonly needed things, but why not just defer to Groovy for those that use it or whatever other API/library anyone might prefer. I know this is a VERY different direction from FM2. What I find most useful in FTL is features like macros and the extensive directives and other things that make a template language flexible and powerful. The built-ins are handy sometimes, but often don't do what I need anyway so other than things like ?has_content I don't use them a lot. I've mentioned this before but what would be a killer feature for FTL is to support pluggable expression evaluators. The FTL expression syntax isn't awful but is not nearly as convenient as Groovy, especially when you are using it extensively elsewhere. If the default FTL expressions were not used you couldn't use built-ins and instead would just have expressions that are expected to evaluate to a boolean, string, or arbitrary object and can be whatever. How important is this? Important enough that I've considered using a different template language. If FTL wasn't so darn convenience for XML transformation using macros I'd probably be using Groovy GString templates instead, and just for the far better syntax in Groovy. This also goes back to the object wrapping discussion which is another can of worms... I don't mean to derail this discussion, but especially these days in a world of a huge number of great Java libraries out there it is often better to not try to do everything and instead focus on core strengths that you can't get anywhere else, and make it easy for people to use other open source projects for their core strengths. This could even go as far as FreeMarker builds that have dependencies on certain commonly used open source projects, there are many even in the ASF that do various things that FTL built-ins do but with far more options and well known behavior for the many who use them (like various Commons projects). Would supporting different expression languages cause huge problems for IDE support? Possibly, but IDEs these days have lots of support for language injection and layers that are meant for just this sort of thing. In theory FreeMarker itself could be a heck of a lot smaller and simpler and at the same time be far more flexible and powerful. IMO that could be a game changer in the world of Java-based template languages. Some of this would be more work than not supporting this sort of flexibility (ie support Groovy syntax as an option, ie without requiring the much larger Groovy jar files as dependencies by having a default built-in expression syntax), but by simplifying other things it would save a heck of a lot of work (including design work). -David On Wed, May 30, 2018 at 5:50 AM, Taher Alkhateeb <[email protected] > wrote: > I'm not a subject matter expert here, but I always thought sensible > defaults with the ability to override using configuration is a wise > move because you appeal to many people out of the box and then allow > minority to also not feel locked out when they need to override. Also, > as a general rule, I found from the projects we worked on that > internationalization is always a challenge, but you can also resolve > that with the same solution (sensible defaults with configuration > overrides); then you simply let the community adopt and improve the > code for non-English parts. > > Of course then the challenge becomes, what's a sensible default? I > wish I had a dollar every time I asked that! I'd favor simplicity > where possible. In your example above maybe "No space f..." is the > simplest, and then people can get fancy if they want to? > > My 2 cents, sorry for the noise :) > > On Wed, May 30, 2018 at 11:59 AM, Daniel Dekany <[email protected]> > wrote: > > There's this old frequently requested built-in, > > maybeTooLongText?truncate(n). Like "No space for such a long > > title"?truncate(13) would give "No space...". The problem with these > > is that there's no single algorithm for this that fits the need of > > everyone. Like maybe the result should be "No space f...", or "No > > space [...]", etc. This can even change depending on the current value > > of the `locale` FreeMarker setting. > > > > Now there's another similar wish, for "?title_case", which has the > > same problem, plus it's much more locale dependent. See: > > > > https://issues.apache.org/jira/browse/FREEMARKER-97 > > > > We do provide locale dependent functions, like number and date > > formatting. This is pretty much an FM tradition, to treat non-English > > users as equals (well, except that the keywords aren't localizable). > > However, we push those tasks to the Java platform. But it doesn't > > support title case (as far as I know). Besides there can be different > > preferences even inside the same country, just as with ?truncate. > > > > So, it's acceptable to chicken out ;) saying that none of the above > > has a widely accepted default, so the correct solution is letting the > > user solve this. But I think in practice what happens is that people > > need the functionality (especially ?truncate), and then has to come up > > with some ad-hoc solution on the spot, which will be almost always > > worse than the default we could provide. So we might as well just > > provide some decent default, sparing time for lot of users. Then, then > > if they are particular about the algorithm (which is certainly rare > > nowadays), let them plug their own via the Configurable API. So there > > would be something like > > cfg.setTruncateImplementation(localToImplementationMap), where the > > parameter maps locale-s to Java functions and defines a fallback > > function. (I haven't worked out the API details, as you can see.) > > > > What do you think? > > > > -- > > Thanks, > > Daniel Dekany > > >
