Re: Looking for contributors as part of Apache incubation

I try to avoid changing the existing public AST API-s (as far as it's
possible when new features are added...) until there's no viable
published API for introspection/modification. For now, the purpose of
the ParserPlugins would be that less users will be forced to depend on
the AST API, because they get the functionality as a ParserPlugin
written by us.


Wednesday, July 1, 2015, 10:25:34 PM, Wong, Christopher wrote:

> I agree that introspection is a tricky business. So far, I have
> adopted your recommendation to use the package local
> TemplateObject.getParameterCount/getParameterValue accessors, but
> that works as long as Freemarker is kind enough to expose the AST.
>
> These are the major things I'm doing with freemarker-introspection:
> - identify custom directives (UnifiedCalls) and their params

For many that would be #import and #include and its *constant*
template name parameter. That information could be given back to the
user through a published API, as it's just Strings. Problems start
when the parameter of interest has some more generic expression as
it's value...

Anyway, can you tell me about the concrete use case in your case?

> - identify variables used

That's possible as we can again just give back a bunch of strings...
or a chains of strings (like ["foo", "bar"] for foo.bar).

> - replace specific elements with something else (takes advantage of begin/end line/column properties)

Here again, the concrete use case might would be interesting.

> Your parser plugin proposal might work for me, if it supplies
> enough information. I could build my own AST as Freemarker does its
> thing. Of course, that pretty much means I'd have to rewrite
> freemarker-introspection. This will hopefully be a longer-term thing
> so I have time to do this. But there could be some uses of
> freemarker-introspection that I could reimplement using the ParserPlugin mechanism instead.
>
> Chris
>
> -----Original Message-----
> From: Daniel Dekany [mailto:[email protected]]
> Sent: Saturday, June 06, 2015 8:26 PM
> To: Wong, Christopher
> Cc: Daniel Dekany
> Subject: Re: [Freemarker-devel] 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

-- 
Thanks,
 Daniel Dekany


------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/