Re: News about Eclipse Freemarker

Hi,

It's great that something is going on again, and needless to say, in a
template language mixing in a HTML highlighting is very useful. If how
much time can I find for helping in it, we will see.

I wonder what will happen when the template is not for generating
HTML. Is there a hope that JFlex tokenizers can be generated by
re-using the common part, the FTL tokenizer? So then we could at least
have a FTL+HTML and an FTL+JustText tokenizer, without maintaining two
FTL tokenizers. (Or the coolest thing would be if the real tokenizer of
FreeMarker is based on the same JFlex tokenizer... and I will have to
rewrite the lexer anyway.)

Another thing... An issue that was probably present in all plugins so
far is that they hard-wire the directives and built-ins into the
lexer/parser. This misconception comes from that most languages has a
small and hardly ever changing set of statement-like stuff, like Java
has "if", "for", etc., and then they have a changing standard API. FTL
is different, as there these two things are one and the same. Anyway,
the situation is in big part the mistake of FreeMarker, as it doesn't
provide a way to query the available core directives and built-ins,
and because the directive syntax is not very regular. Like #list has
an "as" in it, #visit has a "using", etc. It doesn't feel like a
"standard API" that way. But that's something I intend to change in
the future (well, if will I ever get there given the huge FreeMarker
backlog I have), like the recommended form of <#import "foo.ftl" as x>
would be <#import x="foo.ftl">, of <#visit node using ns> would be
<#visit node, using=ns>, etc. It's the syntax of <@...>, except that
you don't have to use "/>" where it's known that the directive can't
have nested content. The old forms will have to remain for
backward-compatibility, and I think the special syntax of #list will
not even be deprecated by the generic one (that would be
<#list xs; x>, which I'm afraid is too scary for newcomers). But
otherwise the plan is that new directives will always follow the
regular syntax. So the lexer/parser should just look for any <#...>
and </#...> tags, then it should query FreeMarker if there's a
directive with that name, and if so, what form it expects inside
(reguar, #list-like, both, etc.), and if it can have a nested content
or it's implicitly closed. The same goes for the built-ins (the ?foo
things). Luckily, the syntax there is regular, but the legal names
(can already be queried in 2.3.20!), and number of accepted parameters
should be queried from FreeMarker again.

If the plugin works like that, updating freemarker.jar is all that's
needed to support new directives and built-ins. Plus, this can be
useful even to check user-defined directive calls (like macro calls,
function calls) in the future.

-- 
Thanks,
 Daniel Dekany


Friday, November 8, 2013, 12:14:53 PM, Angelo zerr wrote:

> Hi Daniel, Greg
>
> For your informaiton, I have restarted from scratch the Freemarker
> Eclipse
> https://github.com/angelozerr/Freemarker-Eclipse-DLTK/tree/master/poc
>
> Why?
>
> My goal is to use Eclipse WTP HTML feature as based of the editor
> to mix HTML and Freemarker like PDT (Eclipse PHP) have done
> https://github.com/eclipse/pdt. They mix DLTK and WTP to manage
> their PHP editor and I would like to do the same thing to benefit with HTML features of WTP.
>
> For the moment, my focus is to manage highlight (highlight HTML
> elements and Freemarker elements). To do that PDT has developped
> their own grammar (jflex) by modyfing the existing
> XMLTokenizer.jflex of WTP. I have started doing the same thing
> https://github.com/angelozerr/Freemarker-Eclipse-DLTK/blob/master/poc/org.eclipse.freemarker.core/devel/FMTokenizer.jflex
>
> and for the moment I can highlight just HTML elements. I discover
> jflex so I must understand how it works.I try to use
> https://bitbucket.org/bazaarvoice/opengrok-patches/src/77be5bfb310b/freemarker-support
>
> If you can help me about this topic, it should be very cool.
>
> Why JFlex? Because WTP uses that and the XMLTokenizer.jflex are
> very robust, so PDT have done this choice. I try to do the same thing than PDT.
>
> If you have time to help me about JFlex topic, it should be very cool. Many thank's.
>
> Regards Angelo


------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk