freemarker-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Dekany <>
Subject Re: FM Online improvements (Was: Graduation issues)
Date Thu, 18 Aug 2016 18:00:40 GMT
Thursday, August 18, 2016, 9:11:34 AM, Pradeep Murugesan wrote:

> Hey Daniel,
>      I have made the changes you have mentioned in the UI side. Yet
> a quick question, You have mentioned auto import shouldn't be a
> checkbox. But you have mentioned like
> "[name       ]  [ ] Auto import  [ ] Auto include" .  
> We should have it as text box right ?

Right, only a text box, no checkbox is needed for auto-import.
Something like:

  Auto import [prefix ]   [ ] Auto include

> Regarding the Configuration , I see that we have a freeMarkerConfig
> (instance of Configuration) and we actually build a Template and
> TemplateConfiguration and is attached to the freemarkerConfig.
> Now in case of additional templates, If we create a Template (with
> name) and TemplateConfiguration for each and attach to the
> freeMarkerConfig (main configuration). 

For now we have no reason to use separate TemplateConfiguration-s, as
there are no UI controls to set any pre-template settings. What we
will need is a separate Configuration for each request when(!) there
are additional templates. That's because the TemplateLoader and
template cache exists on the Configuration level, and each request
will have a different set of additional templates.

> Let me know if I am getting it wrong. 
> Pradeep.
> From: Daniel Dekany <>
> Sent: Wednesday, August 3, 2016 2:22 AM
> To: Pradeep Murugesan
> Subject: Re: FM Online improvements (Was: Graduation issues) 
> Tuesday, August 2, 2016, 2:39:45 PM, Pradeep Murugesan wrote:
>> Hi Daniel,
>>      Got the client side changes and have pushed  @
>> Attached the screenshot of how it will look . Kindly let me know if there are any
> I have just realized that auto-import shouldn't be a checkbox but a
> text imput, as you have to specify the import prefix...
> Now that I see it with 2 additional templates, I think the "+" button
> has some usability disadvantages. People expect the new template to
> appear after the last template (as opposed to be inserted before the
> first one). But the "+" button is always at top. So it would be better
> after the last template. But then it's not entirely obvious what it
> adds. So, how about having only this under the main template textarea
> (note that there's no "Addition templates" title):
>    [Add template] to #import/#include
> where [Add template] is a button, and the text after it is a gray
> hint. Now if someone adds a template, you will have:
>    Template to #import/#include:
>    [name       ]  [ ] Auto import  [ ] Auto include
>    [Enter template, like <#macro greet name>Hello ${name}!</#macro>]
>    [Add template] to #import/#include
> So as you can see, the the [Add template] button will be always at the
> bottom, where the new template will be added if you press it. (If
> someone adds multiple templates, there will be a "Template to
> #import/#include:" label before each.)
> Note that I have also changed the textarea example text.
>> I am going through the server side requirements/changes that needs
>> to be done. Will come back once I have my questions ready.
> One tricky thing will be that FM-Online uses a shared singleton
> Configuration currently, but the additional templates are named, so
> the Configuration need to be aware of them. I guess the best will be
> just creating a new drop-away Configuration instance in case there are
> additional templates. (The other alternative is using a TLS-aware
> TemplateChache, but that's probably too tricky for sparing those CPU
> cycles.) (Yet another alternative is supporting Environment-local
> named templates in FM 2.3.26... but that's the hardest of all.)
>> Pradeep.
>> From: Daniel Dekany <>
>> Sent: Tuesday, August 2, 2016 1:39:01 AM
>> To: Pradeep Murugesan
>> Subject: Re: FM Online improvements (Was: Graduation issues) 
>> Monday, August 1, 2016, 6:11:37 PM, Pradeep Murugesan wrote:
>>> Hi Daniel,
>>>     Got a chance to work on the task. I have come up with something
>>> here
>> Looks fine.
>>> I have the following questions. 
>>> 1. The pure css used by the online validator is pretty old . Do we
>>> have any idea to replace the same with the latest version of
>>> pure( or bootstrap.
>> You can update Pure if you want to, or use Bootstrap CSS... I don't
>> know either. If you have experience with them, I will trust your
>> judgement.
>>> 2. How many such template can the user add. like can he keep on
>>> adding it or we are going to put any restrictions there.
>> To keep users from killing the server, let's say, the main template
>> plus at most 3 importable/includable templates.
>>> Kindly let me know any changes in the pen and also answer to the above.
>>> Pradeep.
>>> From: Daniel Dekany <>
>>> Sent: Monday, June 27, 2016 11:59:34 AM
>>> To: Daniel Dekany
>>> Subject: Re: FM Online improvements (Was: Graduation issues) 
>>> Monday, June 27, 2016, 8:24:21 AM, Daniel Dekany wrote:
>>>> I should
>>> I meant "It should".
>>>> support adding arbitrary templates. As I imagine it, there
>>>> would be an "Add template" button, and when you press it, it adds an
>>>> extra text area, which has a template name input, an "auto import"
>>>> checkbox, and an "auto include" checkbox, and a "Remove template"
>>>> button over it.
>>> Another thing... we should add an "Incompatible improvements" dropdown
>>> after the existing ones, which preselects the value of
>>> Configuration.getVersion().
>>>> Monday, June 27, 2016, 7:24:19 AM, Pradeep Murugesan wrote:
>>>>> Hi Daniel,
>>>>>   Cool..  I will start with adding the extra template name thing to
>>>>> the online template tester. (#import and #include) . I would need
>>>>> more pointers on the same. How have you visualised the same. 
>>>>> Meaning , How the users can import other templates, we will give
>>>>> provision to add other templates or we have some predefined
>>>>> templates loaded , so that they can import the same ?
>>>>> Pradeep.
>>>>> ________________________________
>>>>> From: Daniel Dekany <>
>>>>> Sent: Tuesday, June 14, 2016 11:02:38 PM
>>>>> To: Pradeep Murugesan
>>>>> Cc:
>>>>> Subject: Re: Graduation issues
>>>>> Happy to see you back!
>>>>> There are things to do, of course.
>>>>> I haven't yet merged in your contribution with XML siblings (so it
>>>>> won't be in 2.3.25 - sorry about that, next time), and AFAIR there
>>>>> were some wrinkles to work on.
>>>>> I have done some of the planned improvements on
>>>>> (mostly to draw attention to the
>>>>> outputFormat setting of 2.3.24), but there are other things to do.
>>>>> Apart from what was discussed earlier, I think supporting adding extra
>>>>> templates with names would be handy, because then people can play
>>>>> around with #import and #include.
>>>>> And then of course, there's with
>>>>> even more things to do.
>>>>> Tuesday, June 14, 2016, 12:27:01 PM, Pradeep Murugesan wrote:
>>>>>> Hi Daniel & team,
>>>>>>    Sorry that I was dormant for a long time after a very short tent
>>>>>> @ Freemaker. I am out of some critical issues and have some bandwidth
from now on.
>>>>>> Kindly let me know if there is anything I could help.
>>>>>> Pradeep.
>>>>>> ________________________________
>>>>>> From: Daniel Dekany <>
>>>>>> Sent: Tuesday, June 14, 2016 12:48:55 AM
>>>>>> To: Sergio Fernández
>>>>>> Cc:
>>>>>> Subject: Graduation issues
>>>>>> I think we can start some discussion about that even now. Or at least
>>>>>> I will tell what do I think about the state of the project.
>>>>>> The main problem is the number of active developers, which is 1,
>>>>>> What if I'm hit by a truck tomorrow? We can hope that if there's
a bug
>>>>>> that concerns many, then someone will eventually fix it. After all
>>>>>> owner (ASF) won't be gone, the release infrastructure is there, etc.
>>>>>> But as far as non-bugfix development goes, it's certain that things
>>>>>> would stop. Some may say that that's OK for a project that's
>>>>>> backward-compatibility-locked for 12 years now (the 2.x line is
>>>>>> actually 14 years old). But of course that's just slow death if a
>>>>>> project can't counter its old design problems and can't evolve to
>>>>>> tackle new problems anymore. So indeed 2.x should switch to
>>>>>> maintenance eventually (but ATM there are still things that can be
>>>>>> done in 2.x), but only to give place for 3.x. Anyway, how to catch
>>>>>> long standing developers? I don't think that 2.x have a real chance
>>>>>> for that, because of all the legacy code burden piled up. (Some Apache
>>>>>> projects have many paid contributors, but I think FM isn't the kind
>>>>>> project that can have that, so it's important that the developers
>>>>>> to fiddle with it for free.) So the 3.x jump will be necessary, and
>>>>>> then, maybe, we can have a developer base growth (template engines
>>>>>> isn't hot topic anymore, so I just mean having a few developers
>>>>>> around). But 3.x is far away (if it will happen at all), and we can't
>>>>>> hang around in the incubator forever. So, do you believe there's
>>>>>> chance to graduate with the current developer base?
>>>>>> Monday, June 13, 2016, 8:15:11 AM, Sergio Fernández wrote:
>>>>>>> Besides the technical discussion for 2.3.25-incubating, after
that release
>>>>>>> you may start to discuss a possible graduation. We have to discuss
>>>>>>> aspects (specially growth of the community), but technically
speaking the
>>>>>>> podling is capable os casting releases.
>>>>>> --
>>>>>> Thanks,
>>>>>>  Daniel Dekany
>>>>> --
>>>>> Thanks,
>>>>>  Daniel Dekany

 Daniel Dekany

View raw message