Re: [FM3] Further legacy things to drop...

2017-01-16 Thread Daniel Dekany
Monday, January 16, 2017, 12:22:51 PM, Christoph Rüger wrote: [snip] > NodeModel.getDocumentBuilderFactory(). This is when also the > external entities are resolved and DOM is created. So it would be > good, if this could be customized (either by passing parameters or some other > mechanism).

Re: [FM3] Further legacy things to drop...

2017-01-16 Thread Christoph Rüger
2017-01-16 11:58 GMT+01:00 Daniel Dekany : > Monday, January 16, 2017, 10:05:13 AM, Christoph Rüger wrote: > > [snip] > > The DocumentBuildFactory created > > in freemarker.ext.dom.NodeModel.getDocumentBuilderFactory() is currently > > setup to resolve external entities

Re: [FM3] Further legacy things to drop...

2017-01-13 Thread Daniel Dekany
Friday, January 13, 2017, 1:07:36 PM, Christoph Rüger wrote: > 2017-01-13 1:17 GMT+01:00 Daniel Dekany : > >> Friday, January 13, 2017, 12:08:12 AM, Christoph Rüger wrote: >> >> > +1 for everything. >> > >> > additional security topics: >> > use

Re: [FM3] Further legacy things to drop...

2017-01-13 Thread Christoph Rüger
2017-01-13 1:17 GMT+01:00 Daniel Dekany : > Friday, January 13, 2017, 12:08:12 AM, Christoph Rüger wrote: > > > +1 for everything. > > > > additional security topics: > > use TemplateClassResolver.ALLOWS_NOTHING_RESOLVER by default to > > avoid template injection attacks. > >

Re: [FM3] Further legacy things to drop...

2017-01-12 Thread Daniel Dekany
Yeah, that's one of the parser-related wishes I saw for a few time. I heads it's also possible with JavaCC. This would be also very useful for IDE plugins (the current Eclipse plugin only marks the first error). Anyway, when we get to the template language issues, we shall see what direction that

Re: [FM3] Further legacy things to drop...

2017-01-12 Thread Daniel Dekany
Friday, January 13, 2017, 12:08:12 AM, Christoph Rüger wrote: > +1 for everything. > > additional security topics: > use TemplateClassResolver.ALLOWS_NOTHING_RESOLVER by default to > avoid template injection attacks. At least in FM2 you pull in your TemplateDirectiveModel-s and

Re: [FM3] Further legacy things to drop...

2017-01-12 Thread Jaime Garza
It would be awesome if the parser was able to recover on error and return multiple errors, instead of the first one. Perhaps you may need to use a bottoms-up parser instead of javacc. My customers complain that they need to try the “run” (I use a preview mode actually) multiple times if they

Re: [FM3] Further legacy things to drop...

2017-01-12 Thread David E Jones
These look good to me. Always feels good to clean out old and unneeded code. :) -David On Thu, 2017-01-12 at 23:58 +0100, Daniel Dekany wrote: > I have collected some further easy changes for FM3... Any comments? > > - Drop FTL classic compatible mode option (Roughly emulates FM1 >   behavior

Re: [FM3] Further legacy things to drop...

2017-01-12 Thread Christoph Rüger
+1 for everything. additional security topics: use TemplateClassResolver.ALLOWS_NOTHING_RESOLVER by default to avoid template injection attacks. 2017-01-12 23:58 GMT+01:00 Daniel Dekany : > I have collected some further easy changes for FM3... Any comments? > > - Drop FTL

[FM3] Further legacy things to drop...

2017-01-12 Thread Daniel Dekany
I have collected some further easy changes for FM3... Any comments? - Drop FTL classic compatible mode option (Roughly emulates FM1 behavior at null-s and at some type handling issues) - Drop FTL non-strict syntax option (FM1 syntax - that's where you could write instead of <#if x>). -