Re: Looking for contributors as part of Apache incubation

I'm still not sure what will be done about this (I mean whole topic of
detailed introspection). Right now, what I'm think of is that at some
point (even 2.3.24) I will add something like ParserPlugin, which is
something the user could specify on the Configuration level (maybe per
template name pattern). That means that a parser plugin can
participate in the parsing, because it was there before the template
parsing was started. This already eliminates some compatibility risks
(like what if Template-s won't contain an AST anymore, but generated
byte code for example - this can work even then). The plugin could
attach arbitrary attributes to the template (see custom attributes) to
store plugin output (if any), or even change the template.

So how does is make backward compatibility easier (apart from what was
already said above)? For now the user couldn't define custom
plugins... FM itself (or some additional optional artifacts) would,
define some plugins that cover the most frequent needs, and the user
only has the power to chose among these plugins. Two frequent things
that we could solve with a plugin are:

- Collecting the names of maybe-data-model variables used (to find out the
  requires data-model variables for a template)

- Collecting the includes/imports (to analyze which template depends on
  which)

So this hopefully somewhat alleviates the need for more detailed
template introspection (such as walking the AST), while we haven't
exposed much from the internals (and hence from the things that we may
want to change later).

What exactly was template introspection used for in your use case?

BTW, a plugin that I will make is the interruptible template plugin. A
template to which that plugin was associated will support
Thread.interrupt() on the running template. This functionality
(template interruptability) is already present in 2.3.22, but is only
accessibly through internal API-s, and is used on freemarker-online to
automatically abort long running templates.

-- 
Thanks,
 Daniel Dekany


Tuesday, June 2, 2015, 5:12:52 PM, Wong, Christopher wrote:

> Concerning the "public template introspection API", I'd like to
> provide an update on my freemarker-introspection project:
>
> https://github.com/cwong15/freemarker-introspection
>
> I've updated the code to support the latest Freemarker (2.3.22). To
> inspect the parsed Freemarker AST, it now uses package-local access
> instead of reflection for more robust Freemarker compatibility. I'm
> open to recommendations on how to progress towards making this part
> of the Freemarker project somehow.
>
> Chris
>
> -----Original Message-----
> From: Daniel Dekany [mailto:[email protected]]
> Sent: Saturday, May 30, 2015 6:21 AM
> To: [email protected]
> Subject: [Freemarker-devel] Looking for contributors as part of Apache incubation
>
> We are (or mostly, I'm) trying to move FreeMarker over to the
> Apache Software Foundation. So far the reaction is mostly positive
> on Apache's side, but, the major concern is the low number of active
> contributors. If everything goes well, there will be a voting about
> letting FreeMarker in into the Apache *Incubator*, where it will
> have to build up some kind of community or else it will fail. OTOH
> the main reason I want FM to be an Apache project is exactly to
> improve chances of finding contributors, especially long term ones like myself.
> Obviously, one man (me) is not very safe for the users (like what
> if something happens with me, or I just move on).
>
> So, I just wonder if I can expect anyone to join the incubation
> when and if it will be started. There's lot of interesting but
> difficult tasks to do. Like better automatic escaping, a new parser
> that's more IDE friendly and faster and has better error messages,
> proper support of Map-s with non-string keys, better null handling,
> advanced white-space removal, better caching, better i18n,
> supporting custom "dialects" (i.e., changing the set of built-ins
> and built-in directives), public template introspection API, better
> debugging, Android support, and many more. It was just a glimpse.
> There's a lot of space for advancement.
>
> --
> Best regards,
>  Daniel Dekany


------------------------------------------------------------------------------