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 <[email protected]> > 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 @ >> https://github.com/pradeepmurugesan/freemarker-online/tree/additionalTemplates. >> >> Attached the screenshot of how it will look . Kindly let me know if there >> are any changes. > > 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 <[email protected]> >> 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 http://codepen.io/pradeepmurugesan/pen/oLPNgQ. >> >> 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(http://purecss.io/) 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 <[email protected]> >>> 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 <[email protected]> >>>>> Sent: Tuesday, June 14, 2016 11:02:38 PM >>>>> To: Pradeep Murugesan >>>>> Cc: [email protected] >>>>> 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 >>>>> http://freemarker-online.kenshoo.com/ (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 http://freemarker.org/contribute.html 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 <[email protected]> >>>>>> Sent: Tuesday, June 14, 2016 12:48:55 AM >>>>>> To: Sergio Fernández >>>>>> Cc: [email protected] >>>>>> 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, me. >>>>>> 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 the >>>>>> 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 of >>>>>> project that can have that, so it's important that the developers want >>>>>> 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 any >>>>>> 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 many >>>>>>> aspects (specially growth of the community), but technically speaking >>>>>>> the >>>>>>> podling is capable os casting releases. >>>>>> >>>>>> -- >>>>>> Thanks, >>>>>> Daniel Dekany >>>>>> >>>>> >>>>> -- >>>>> Thanks, >>>>> Daniel Dekany >>>>> >>>> >>> >> > -- Thanks, Daniel Dekany
