Re: [FM3] Configuration mutability (Was: [FM3] Configuration API simplification)

2017-02-16 Thread Woonsan Ko
On Thu, Feb 16, 2017 at 1:28 PM, Daniel Dekany wrote: > One other problem I see with builders is that they seem to be > difficult to work with when it comes to working out the Configuration > setting values in multiple stages. > > What do I mean by multiple stages? For

Re: Pluggable template retrival/caching logic (Was: Template Loader Implementation that loads from a database (DataSource))

2017-02-16 Thread Daniel Dekany
Note that there's quick draft of TemplateResolver committed in the "3" branch: https://github.com/apache/incubator-freemarker/blob/3/src/main/java/org/apache/freemarker/core/templateresolver/TemplateResolver.java It's not integrated with the other parts of FM (it's assumed everywhere that we have

Re: Pluggable template retrival/caching logic (Was: Template Loader Implementation that loads from a database (DataSource))

2017-02-16 Thread Daniel Dekany
Thursday, February 16, 2017, 5:33:01 PM, David E Jones wrote: > On Thu, 2017-02-16 at 15:56 +0100, Daniel Dekany wrote: >> Thursday, February 16, 2017, 6:17:00 AM, David E Jones wrote: >> >> > >> > This is cleaner, more obvious what's going on underneath, but since >> > the

Re: [FM3] Configuration mutability (Was: [FM3] Configuration API simplification)

2017-02-16 Thread Daniel Dekany
One other problem I see with builders is that they seem to be difficult to work with when it comes to working out the Configuration setting values in multiple stages. What do I mean by multiple stages? For example, the user specifies some settings in the web.xml in the case of FreemarkeServlet,

Re: Pluggable template retrival/caching logic (Was: Template Loader Implementation that loads from a database (DataSource))

2017-02-16 Thread David E Jones
On Thu, 2017-02-16 at 15:56 +0100, Daniel Dekany wrote: > Thursday, February 16, 2017, 6:17:00 AM, David E Jones wrote: > > > > > This is cleaner, more obvious what's going on underneath, but since > > the DefaultTemplateResolver will be the most commonly used you > > could just leave the

Re: Pluggable template retrival/caching logic (Was: Template Loader Implementation that loads from a database (DataSource))

2017-02-16 Thread Daniel Dekany
Thursday, February 16, 2017, 6:17:00 AM, David E Jones wrote: > > This is cleaner, more obvious what's going on underneath, but since > the DefaultTemplateResolver will be the most commonly used you > could just leave the current setting methods as they are and just > document that if you set a

Re: [FM3] improve “null” handling

2017-02-16 Thread Pedro M. Zamboni
Hello, Daniel, thanks for the quick reply. Sorry for not being able to respond as quickly. > […] many languages differentiate between an undefined variable (or member) > […] and an existing variable (or member) that holds null. […] [I]n FM3 I do > consider differentiating the two cases