freemarker-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David E Jones <...@dejc.com>
Subject Re: The problem of "too human" text transformations
Date Wed, 30 May 2018 23:16:26 GMT
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 <slidingfilaments@gmail.com
> 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 <ddekany@apache.org>
> 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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message