"freemarker", "site" and "docgen" Git repos moved to ASF
As part of the incubation process at Apache Software Foundation, our 3 main Git repos has been imported from GitHub into ASF's infrastructure, and from now on, all commits must go there, not to GitHub. Old repo URL -> New repo URL https://github.com/freemarker/freemarker.git -> https://git-wip-us.apache.org/repos/asf/incubator-freemarker.git https://github.com/freemarker/site.git -> https://git-wip-us.apache.org/repos/asf/incubator-freemarker-site.git https://github.com/freemarker/docgen.git -> https://git-wip-us.apache.org/repos/asf/incubator-freemarker-docgen.git The repos can be cloned from the above URL-s, of course. Also note that the copyright headers etc. were changed so that the owner is ASF now. -- Thanks, Daniel Dekany
Re: Please review/sign Incubator PMC report for September 2015
Note that I have changed the text to reflect that we have already imported the project. I hope it's not a problem: How has the community developed since the last report? We are still in early stage of incubation (like source code was only imported recently), so not much is happening inside ASF yet. One new contributor has found us through ASF. How has the project developed since the last report? GitHub import was done, we are starting the IP clearance process. (On GitHub the project was highly active.) Wednesday, September 2, 2015, 6:33:35 AM, Jacopo Cappellato wrote: > The report looks good to me, I have checked my box. > Some minor suggestions for the report: > > * I would suppress the sentence: "[...] working on code that's not > part of the incubating code base." > * instead of "[..] then we are soon starting the IP clearance > voting" I would say "[...] then we are soon starting the IP clearance > process". > > Regards, > > Jacopo > > On Sep 2, 2015, at 1:54 AM, Daniel Dekany wrote: > >> Dear mentors! Please read our monthly report, and check the checkboxes >> if you agree: https://wiki.apache.org/incubator/September2015#preview >> >> -- >> Thanks, >> Daniel Dekany >> > > -- Thanks, Daniel Dekany
[Mentors] Starting IP clearance process?
Dear Mentors (and others who want to help), We have the 3 repos (freemarker, docgen, site) imported as you might noticed from the flood of commit messages (sorry...), and I have changed the copyright headers, ensured that the 3 standard legal files (NOTICE, LICENSE and DISCLAIMER) are there, and removed files that I have spotted with unclear copyright. So, gloss over the 3 projects if you want to, and then I think I should add a tag like "ip-clearance", and the more official review could be started. Or something like that... Please advise! -- Thanks, Daniel Dekany
[Mentors] Project status page
I guess http://incubator.apache.org/projects/freemarker.html need some updating. (I'm not supposed to edit that, AFAIR.) Also, I will ask infra to direct commit messages to notificati...@freemarker.incubator.apache.org (if you agree). -- Thanks, Daniel Dekany
Re: [Mentors] Starting IP clearance process?
Thursday, September 3, 2015, 12:56:50 AM, Daniel Dekany wrote: > Dear Mentors (and others who want to help), > > We have the 3 repos (freemarker, docgen, site) imported as you might > noticed from the flood of commit messages (sorry...), and I have > changed the copyright headers, ensured that the 3 standard legal files > (NOTICE, LICENSE and DISCLAIMER) are there, and removed files that I > have spotted with unclear copyright. So, gloss over the 3 projects if > you want to, and then I think I should add a tag like "ip-clearance", > and the more official review could be started. Or something like > that... Please advise! Oh, regarding the "freemarker" repo... it's a bit tricky. It has 3 alive branches, so the clearance has to be done in all of them: master, 2.3-gae and 2.3. Also, there's a second LICENSE and NOTICE file variation under src/dist, because the distribution tar.gz includes the generated documentation, which complicates legal things a bit. -- Thanks, Daniel Dekany
Re: Rest Service for FreeMarkerOnline
I will... tomorrow or at the weekend. Thursday, September 3, 2015, 8:27:15 PM, Pradeep Murugesan wrote: > Hi Daniel, > Kindly review when ever you find time. > https://github.com/pradeepmurugesan/freemarker-online/commit/4445f45997c1eaf76c6b4e13e8c2054ee163e034https://github.com/pradeepmurugesan/freemarker-online/commit/d8e25be864a25596d29f875fa845695d02168e26 > Pradeep. >> From: pradeepmuruge...@outlook.com >> Subject: Re: Rest Service for FreeMarkerOnline >> Date: Tue, 1 Sep 2015 23:40:38 +0530 >> To: dev@freemarker.incubator.apache.org >> >> Yup.. Finishing the current task is the priority. >> >> Pradeep. >> >> > On 01-Sep-2015, at 10:09 pm, "Daniel Dekany" wrote: >> > >> > Tuesday, September 1, 2015, 10:01:31 AM, Pradeep Murugesan wrote: >> > >> >> Sure Daniel, >> >> I will change the initialization @ method level. >> >> I have a couple of questions. Please reply when you find time. Sorry If >> >> its too naive. >> >> 1. I tried to check whether jersey's resource methods are singleton >> >> but found in the doc that they spawn a thread for each request. And >> >> we may turn on the singleton thing if required through some explicit >> >> settings. >> > >> > It's Spring bean (@Component), and those are singletons by default. >> > Even if wasn't a singleton, I see no reason for a response object to >> > be recycled between requests. It can be the source for hideous bugs, >> > as you start with a dirty object, etc. >> > >> >> I browsed our code to see if we have some setting but >> >> couldn't find anything. >> > >> > The easiest is just trying it with some log messages. >> > >> >> In 3.4 of >> >> https://jersey.java.net/nonav/documentation/latest/user-guide.html#d0e2586 >> >> we can see they mentioning the above. >> >> 2. In the mean time I am trying to get hold of how freemarker >> >> template engine works by trying to fix some low hanging bugs so that >> >> I can understand the architecture better. I am browsing for issues >> >> here http://sourceforge.net/p/freemarker/bugs/. Kindly let me know a >> >> good place or a minor bug to start with. >> > >> > Most bugs will be stuff that isn't fixed because it's tricky to fix >> > them, often because of backward compatibility requirements... But for >> > example here's this new one: >> > http://sourceforge.net/p/freemarker/bugs/434/ Could be checked if it's >> > true, and why it happens. But of course deal what we feel like with. >> > >> > (It's also a good idea to polishing what you have started, like >> > writing the JUnit tests, etc.) >> > >> >> Pradeep. >> >> >> >>> Date: Mon, 31 Aug 2015 20:49:34 +0200 >> >>> From: ddek...@freemail.hu >> >>> To: dev@freemarker.incubator.apache.org >> >>> Subject: Re: Rest Service for FreeMarkerOnline >> >>> >> >>> OK, thanks! I will be rather busy for a few days, so it might will >> >>> take a while until I check this out in detail. But I assume you know >> >>> of things that you wanted to finish/polish anyway. >> >>> >> >>> Something I have spotted with this quick look now is that >> >>> executeResponse shouldn't be a field in >> >>> FreeMarkerOnlineExecuteResource, as I suppose the resource object is a >> >>> singleton used by multiple threads. >> >>> >> >>> >> >>> Monday, August 31, 2015, 3:21:09 PM, Pradeep Murugesan wrote: >> >>> >> >>>> Hi Daniel, >> >>>> >> >>>> https://github.com/pradeepmurugesan/freemarker-online/commit/71e70d6caf9bead735ca0f2b6eb4f81c708a1922 >> >>>> I have fixed the code review comments and integrated the same with UI. >> >>>> Please let me know your reviews. >> >>>> >> >>>> Pradeep. >> >>>> >> >>>>> Date: Mon, 31 Aug 2015 12:22:17 +0200 >> >>>>> From: ddek...@freemail.hu >> >>>>> To: dev@freemarker.incubator.apache.org >> >>>>> Subject: Re: Rest Service for FreeMarkerOnline >> >>>>> >> >>>>> Certainly it's good enough to go ahead with the UI. >> >>>>>
Re: FreeMarker Online - Embedding IDE.
Thursday, September 3, 2015, 8:41:23 PM, Pradeep Murugesan wrote: > Hi Daniel, >Right now we have text areas for template and dataModel. can > we embed a kind of on-line code editor instead of text areas. Sure, it's even on http://freemarker.org/contribute.html. > one quick example came to my mind is http://ace.c9.io/#nav=embedding > We can also write a freemarker syntax highlighter as a plugin for > this editor. Having a layout similar to CodePen or plunker will make > it look good. Yes, that would be the ultimate goal. (If you will start working on something reusable like that, it should be independently of FM-Online.) > I also though of some ready made examples ( template + datamodel ) > which user can just click and it will populate the editor. With this > we can actually make the user understand the real powerful features > that FreeMarker is having. Yes, that's a good idea! Such feature demos could also be linked from the Manual too. (All examples in the manual should be runnable on FM-Online with a click, ideally.) > Just some random thoughts when I was thinking how to make this on-line tool > better. > Let me know your inputs. > Pradeep. -- Thanks, Daniel Dekany
Re: FreeMarker Online - Embedding IDE.
Thursday, September 3, 2015, 10:28:51 PM, Daniel Dekany wrote: > Thursday, September 3, 2015, 8:41:23 PM, Pradeep Murugesan wrote: > >> Hi Daniel, >>Right now we have text areas for template and dataModel. can >> we embed a kind of on-line code editor instead of text areas. > > Sure, it's even on http://freemarker.org/contribute.html. > >> one quick example came to my mind is http://ace.c9.io/#nav=embedding >> We can also write a freemarker syntax highlighter as a plugin for >> this editor. Having a layout similar to CodePen or plunker will make >> it look good. > > Yes, that would be the ultimate goal. (If you will start working on > something reusable like that, it should be independently of > FM-Online.) I meant the highlighter for Ace here... -- Thanks, Daniel Dekany
Git commit notifications mailing list changed
This is where commit notifications go from now on: notificati...@freemarker.incubator.apache.org To subscribe: mailto:notifications-subscr...@freemarker.incubator.apache.org Also soon we will be have the mirror on GitHub, so you could get the notifications from there too. dev@freemarker.incubator.apache.org will NOT get the commit notifications anymore. -- Thanks, Daniel Dekany
Re: FreeMarker Online - Embedding IDE.
It should be updated to support the new built-ins, directives, etc., and camel case. Otherwise it's already much better than a plan text area in that it auto-indents and such. Friday, September 4, 2015, 4:19:47 AM, Pradeep Murugesan wrote: > Hey Daniel, > Thought to work on syntax highlighter for FM in ACE and > really happy to see that we already have a mode for FM in Ace. > http://ace.c9.io/tool/mode_creator.html > I think we can just go ahead and embed the editor set the mode to > FreeMarker , we will get IDE support :-) . > Pradeep. > >> Date: Thu, 3 Sep 2015 22:34:04 +0200 >> From: ddek...@freemail.hu >> To: dev@freemarker.incubator.apache.org >> Subject: Re: FreeMarker Online - Embedding IDE. >> >> Thursday, September 3, 2015, 10:28:51 PM, Daniel Dekany wrote: >> >> > Thursday, September 3, 2015, 8:41:23 PM, Pradeep Murugesan wrote: >> > >> >> Hi Daniel, >> >>Right now we have text areas for template and dataModel. can >> >> we embed a kind of on-line code editor instead of text areas. >> > >> > Sure, it's even on http://freemarker.org/contribute.html. >> > >> >> one quick example came to my mind is http://ace.c9.io/#nav=embedding >> >> We can also write a freemarker syntax highlighter as a plugin for >> >> this editor. Having a layout similar to CodePen or plunker will make >> >> it look good. >> > >> > Yes, that would be the ultimate goal. (If you will start working on >> > something reusable like that, it should be independently of >> > FM-Online.) >> >> I meant the highlighter for Ace here... >> >> -- >> Thanks, >> Daniel Dekany >> > -- Thanks, Daniel Dekany
Re: [Freemarker-devel] "freemarker", "site" and "docgen" Git repos moved to ASF
Yes, thanks, I have requested them, and now they have here: https://github.com/apache/incubator-freemarker https://github.com/apache/incubator-freemarker-site https://github.com/apache/incubator-freemarker-docgen Thursday, September 3, 2015, 5:38:52 AM, Woonsan Ko wrote: > Hi Daniel, > > That's great! > Could we be benefited from GitHub integration (Apache git mirror on > Github) as well? In other projects such as commons-scxml, it was done > with INFRA ticket [1]. This could help more people get involved easily. > > Regards, > > Woonsan > > [1] https://issues.apache.org/jira/browse/INFRA-9961 > > On 9/2/15 5:17 PM, Daniel Dekany wrote: >> As part of the incubation process at Apache Software Foundation, our 3 >> main Git repos has been imported from GitHub into ASF's >> infrastructure, and from now on, all commits must go there, not to >> GitHub. >> >> Old repo URL -> New repo URL >> https://github.com/freemarker/freemarker.git -> >> https://git-wip-us.apache.org/repos/asf/incubator-freemarker.git >> https://github.com/freemarker/site.git -> >> https://git-wip-us.apache.org/repos/asf/incubator-freemarker-site.git >> https://github.com/freemarker/docgen.git -> >> https://git-wip-us.apache.org/repos/asf/incubator-freemarker-docgen.git >> >> The repos can be cloned from the above URL-s, of course. >> >> Also note that the copyright headers etc. were changed so that the >> owner is ASF now. >> > > > -- > Monitor Your Dynamic Infrastructure at Any Scale With Datadog! > Get real-time metrics from all of your servers, apps and tools > in one place. > SourceForge users - Click here to start your Free Trial of Datadog now! > http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 > ___ > FreeMarker-devel mailing list > freemarker-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freemarker-devel > -- Thanks, Daniel Dekany
Re: Rest Service for FreeMarkerOnline
I have looked at it now. I haven't seen any big issues. I ran into small things (some of you may know about): - Bug: Template-related errors point to the dataModel in the response JSON - Bug: The validForm function in script.js... you will see if you look at it. I think blocking submissions with empty template is good, and empty data-model is not a problem. - All the old non-AJAX code can be removed now - Cleaning up stuff like unnecessary buildFreeMarkerResponse method, debug logs in scrip.js, etc. Also naming cleanup, like FreeMarkerError to ErrorCode. And use name() instead of toString() for enums. - Submitting makes the edit boxes "flash", as you quickly disable and enable them. I think it's kind of unpleasant. Maybe you just shouldn't disable them, only the submitt button, and then show the usual spinning wheel over the output area. Or something like that. - The selenium JUnit test fails. I guess it won't work with AJAX anyway, so it will have to be removed, but I haven't looked into it. - Can `Map problems` be a `Map`? I'm not sure if Jeresy will handle that, but if it does, it's cleaner. Monday, September 7, 2015, 4:25:12 PM, Pradeep Murugesan wrote: > Hi Daniel, Got a chance to review this ? > Pradeep. > >> Date: Thu, 3 Sep 2015 22:17:38 +0200 >> From: ddek...@freemail.hu >> To: dev@freemarker.incubator.apache.org >> Subject: Re: Rest Service for FreeMarkerOnline >> >> I will... tomorrow or at the weekend. >> >> >> Thursday, September 3, 2015, 8:27:15 PM, Pradeep Murugesan wrote: >> >> > Hi Daniel, >> > Kindly review when ever you find time. >> > https://github.com/pradeepmurugesan/freemarker-online/commit/4445f45997c1eaf76c6b4e13e8c2054ee163e034https://github.com/pradeepmurugesan/freemarker-online/commit/d8e25be864a25596d29f875fa845695d02168e26 >> > Pradeep. >> >> From: pradeepmuruge...@outlook.com >> >> Subject: Re: Rest Service for FreeMarkerOnline >> >> Date: Tue, 1 Sep 2015 23:40:38 +0530 >> >> To: dev@freemarker.incubator.apache.org >> >> >> >> Yup.. Finishing the current task is the priority. >> >> >> >> Pradeep. >> >> >> >> > On 01-Sep-2015, at 10:09 pm, "Daniel Dekany" >> >> > wrote: >> >> > >> >> > Tuesday, September 1, 2015, 10:01:31 AM, Pradeep Murugesan wrote: >> >> > >> >> >> Sure Daniel, >> >> >> I will change the initialization @ method level. >> >> >> I have a couple of questions. Please reply when you find time. Sorry >> >> >> If its too naive. >> >> >> 1. I tried to check whether jersey's resource methods are singleton >> >> >> but found in the doc that they spawn a thread for each request. And >> >> >> we may turn on the singleton thing if required through some explicit >> >> >> settings. >> >> > >> >> > It's Spring bean (@Component), and those are singletons by default. >> >> > Even if wasn't a singleton, I see no reason for a response object to >> >> > be recycled between requests. It can be the source for hideous bugs, >> >> > as you start with a dirty object, etc. >> >> > >> >> >> I browsed our code to see if we have some setting but >> >> >> couldn't find anything. >> >> > >> >> > The easiest is just trying it with some log messages. >> >> > >> >> >> In 3.4 of >> >> >> https://jersey.java.net/nonav/documentation/latest/user-guide.html#d0e2586 >> >> >> we can see they mentioning the above. >> >> >> 2. In the mean time I am trying to get hold of how freemarker >> >> >> template engine works by trying to fix some low hanging bugs so that >> >> >> I can understand the architecture better. I am browsing for issues >> >> >> here http://sourceforge.net/p/freemarker/bugs/. Kindly let me know a >> >> >> good place or a minor bug to start with. >> >> > >> >> > Most bugs will be stuff that isn't fixed because it's tricky to fix >> >> > them, often because of backward compatibility requirements... But for >> >> > example here's this new one: >> >> > http://sourceforge.net/p/freemarker/bugs/434/ Could be checked if it's >> >> > true, and why it happens. But of course deal what we feel like with. >> >> > &
Re: Using FreeMarkers Parser and Lexer
That the related API-s are not public or are public but marked as internal/deprecated is because FM doesn't provide backward compatibility there. So you might as well copy them into your package and change the visibilities, etc. What exactly do you want to achieve? Thursday, September 10, 2015, 11:33:42 AM, Malte Brunnlieb wrote: > Hi all, > > due to my current research, I try to access FreeMarkers Parser and/or > Lexer appropriately, but it seems, that you have already successfully > hidden the most necessary classes to do so. > The only thing, I am currently able to do is to get the parsed element > root. Nevertheless, also this API seems to be deprecated. > > I also tried to work directly with the FTL.jj defintion, but you adapted > the API of the Parser and Lexer Exceptions I cannot simply reuse from > your library. > > I know that my issue is a very special and advanced use case, but do you > see any possibility to work with the latest FreeMarker Lexer/Parser by > simple library reuse? > > Best Regards, > Malte > > -- Thanks, Daniel Dekany
Re: Rest Service for FreeMarkerOnline
Friday, September 11, 2015, 1:30:27 PM, Pradeep Murugesan wrote: > Hi Daniel, > > Have fixed things. Except for the following > 1. All the old non-AJAX code can be removed now I thought > we would be needing this when we try to connect FM-online from user manual. You meant the examples in the manual would do a HTTP POST that immediately run the code. I think you are right, that would be better then filling the form with a POST, and then starting an AJAX request. However, the amount of code duplication should minimized (if it wasn't). Also we will need a test just for this case. > 2. Regarding the Ajax spinner I have used the blockUI library > http://malsup.com/jquery/block/. Let me know if we need to change this. I think it will be good, because it only starts to change the screen after a while, so for fast executions you see no flashing or such. Certainly it need to be adjusted though, as the on-line service certainly won't respond that fast, so the darkening will be started too early. > 3. Web driver test - I am trying to make it work. I suspect the selenium thing will only cover the initial POST (the Manual use case). When the JUnit coverage is good enough, I think you should make a pull request. (Tell me when you are about doing that, so that I can check the thing for the last time.) > Others , I have fixed and pushed. > https://github.com/pradeepmurugesan/freemarker-online/commit/22e310f7112ce28c470e162893984940b720c8c0 > > Pradeep. >> Date: Mon, 7 Sep 2015 23:32:01 +0200 >> From: ddek...@freemail.hu >> To: dev@freemarker.incubator.apache.org >> Subject: Re: Rest Service for FreeMarkerOnline >> >> I have looked at it now. I haven't seen any big issues. I ran into >> small things (some of you may know about): >> >> - Bug: Template-related errors point to the dataModel in the response JSON >> >> - Bug: The validForm function in script.js... you will see if you look at >> it. I think blocking submissions with empty template is good, and >> empty data-model is not a problem. >> >> - All the old non-AJAX code can be removed now >> >> - Cleaning up stuff like unnecessary buildFreeMarkerResponse method, >> debug logs in scrip.js, etc. Also naming cleanup, like >> FreeMarkerError to ErrorCode. And use name() instead of >> toString() for enums. >> >> - Submitting makes the edit boxes "flash", as you quickly disable and >> enable them. I think it's kind of unpleasant. Maybe you just >> shouldn't disable them, only the submitt button, and then show the >> usual spinning wheel over the output area. Or something like that. >> >> - The selenium JUnit test fails. I guess it won't work with AJAX >> anyway, so it will have to be removed, but I haven't looked into it. >> >> - Can `Map problems` be a >> `Map`? I'm not sure if Jeresy >> will handle that, but if it does, it's cleaner. >> >> >> Monday, September 7, 2015, 4:25:12 PM, Pradeep Murugesan wrote: >> >> > Hi Daniel, Got a chance to review this ? >> > Pradeep. >> > >> >> Date: Thu, 3 Sep 2015 22:17:38 +0200 >> >> From: ddek...@freemail.hu >> >> To: dev@freemarker.incubator.apache.org >> >> Subject: Re: Rest Service for FreeMarkerOnline >> >> >> >> I will... tomorrow or at the weekend. >> >> >> >> >> >> Thursday, September 3, 2015, 8:27:15 PM, Pradeep Murugesan wrote: >> >> >> >> > Hi Daniel, >> >> > Kindly review when ever you find time. >> >> > https://github.com/pradeepmurugesan/freemarker-online/commit/4445f45997c1eaf76c6b4e13e8c2054ee163e034https://github.com/pradeepmurugesan/freemarker-online/commit/d8e25be864a25596d29f875fa845695d02168e26 >> >> > Pradeep. >> >> >> From: pradeepmuruge...@outlook.com >> >> >> Subject: Re: Rest Service for FreeMarkerOnline >> >> >> Date: Tue, 1 Sep 2015 23:40:38 +0530 >> >> >> To: dev@freemarker.incubator.apache.org >> >> >> >> >> >> Yup.. Finishing the current task is the priority. >> >> >> >> >> >> Pradeep. >> >> >> >> >> >> > On 01-Sep-2015, at 10:09 pm, "Daniel Dekany" >> >> >> > wrote: >> >> >> > >> >> >> > Tuesday, September 1, 2015, 10:01:31 AM, Pradeep Murugesan wrote: >> >> >> > >> >> >> >> Sure Daniel, >> >> >> >>
Re: template inclusions cause stackoverflowerror
rker-2.3.22.jar:2.3.22] > at > freemarker.core.MixedContent.accept(MixedContent.java:62) > [freemarker-2.3.22.jar:2.3.22] > at > freemarker.core.Environment.visitByHiddingParent(Environment.java:333) > [freemarker-2.3.22.jar:2.3.22] > at > freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:48) > [freemarker-2.3.22.jar:2.3.22] > at > freemarker.core.Environment.visitByHiddingParent(Environment.java:333) > [freemarker-2.3.22.jar:2.3.22] > at > freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:48) > [freemarker-2.3.22.jar:2.3.22] > at freemarker.core.Environment.visit(Environment.java:312) > [freemarker-2.3.22.jar:2.3.22] > at > freemarker.core.MixedContent.accept(MixedContent.java:62) > [freemarker-2.3.22.jar:2.3.22] > at freemarker.core.Environment.visit(Environment.java:312) > [freemarker-2.3.22.jar:2.3.22] > at freemarker.core.EscapeBlock.accept(EscapeBlock.java:48) > [freemarker-2.3.22.jar:2.3.22] > at freemarker.core.Environment.visit(Environment.java:312) > [freemarker-2.3.22.jar:2.3.22] > at > freemarker.core.Environment.process(Environment.java:290) > [freemarker-2.3.22.jar:2.3.22] > at freemarker.template.Template.process(Template.java:312) > [freemarker-2.3.22.jar:2.3.22] > > [2] > > at > freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458) > at > freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:71) > at freemarker.core.MethodCall._eval(MethodCall.java:62) > at freemarker.core.Expression.eval(Expression.java:78) > at freemarker.core.ReturnInstruction.accept(ReturnInstruction.java:35) > at freemarker.core.Environment.visit(Environment.java:336) > at freemarker.core.Macro$Context.runMacro(Macro.java:186) > at freemarker.core.Environment.invoke(Environment.java:705) > at freemarker.core.MethodCall._eval(MethodCall.java:74) > at freemarker.core.Expression.eval(Expression.java:78) > at > freemarker.core.Expression.evalAndCoerceToString(Expression.java:82) > at freemarker.core.DollarVariable.accept(DollarVariable.java:41) > at freemarker.core.Environment.visit(Environment.java:336) > at freemarker.core.Environment.visit(Environment.java:341) > at > freemarker.core.Environment.renderElementToString(Environment.java:2200) > at > freemarker.core.StringLiteral.evalAndCoerceToString(StringLiteral.java:96) > at freemarker.core.StringLiteral._eval(StringLiteral.java:73) > at freemarker.core.Expression.eval(Expression.java:78) > at > freemarker.core.Environment.setMacroContextLocalsFromArguments(Environment.java:743) > at freemarker.core.Environment.invoke(Environment.java:693) > at freemarker.core.UnifiedCall.accept(UnifiedCall.java:85) > at freemarker.core.Environment.visit(Environment.java:336) > at freemarker.core.Environment.visit(Environment.java:341) > at freemarker.core.Environment.visit(Environment.java:341) > at freemarker.core.Environment.process(Environment.java:302) > at freemarker.template.Template.process(Template.java:325) -- Thanks, Daniel Dekany
Fwd: [Mentors] Starting IP clearance process?
Just wanted to bring the below mail to your attention, as it was now 9 days without any reaction. This is a forwarded message From: Daniel Dekany To: dev@freemarker.incubator.apache.org Date: Thursday, September 3, 2015, 12:56:50 AM Subject: [Mentors] Starting IP clearance process? ===8<==Original message text=== Dear Mentors (and others who want to help), We have the 3 repos (freemarker, docgen, site) imported as you might noticed from the flood of commit messages (sorry...), and I have changed the copyright headers, ensured that the 3 standard legal files (NOTICE, LICENSE and DISCLAIMER) are there, and removed files that I have spotted with unclear copyright. So, gloss over the 3 projects if you want to, and then I think I should add a tag like "ip-clearance", and the more official review could be started. Or something like that... Please advise! -- Thanks, Daniel Dekany ===8<===End of original message text===
Re: Fwd: [Mentors] Starting IP clearance process?
Saturday, September 12, 2015, 10:49:37 AM, Sergio Fernández wrote:
> Daniel, sorry, I'll try to go through this on Monday.
>
> For provenance purposes what it's important is to have tagged in both repos
> (original and asf) the concrete version that has been donated.
I have added "donated-to-asf" tags in both the GitHub and ASF repos.
More precisely, as the "freemarker" repository (as opposed to the
"site" and "docgen" repos) has 3 branches ("2.3-gae", "2.3" and
"master"), there we have "2.3-gae-donated-to-asf" and
"2.3-donated-to-asf" and "master-donated-to-asf", respectively.
--
Thanks,
Daniel Dekany
> On Sep 12, 2015 10:02 AM, "Daniel Dekany" wrote:
>
>> Just wanted to bring the below mail to your attention, as it was now 9
>> days without any reaction.
>>
>>
>> This is a forwarded message
>> From: Daniel Dekany
>> To: dev@freemarker.incubator.apache.org
>> Date: Thursday, September 3, 2015, 12:56:50 AM
>> Subject: [Mentors] Starting IP clearance process?
>>
>> ===8<==Original message text===
>> Dear Mentors (and others who want to help),
>>
>> We have the 3 repos (freemarker, docgen, site) imported as you might
>> noticed from the flood of commit messages (sorry...), and I have
>> changed the copyright headers, ensured that the 3 standard legal files
>> (NOTICE, LICENSE and DISCLAIMER) are there, and removed files that I
>> have spotted with unclear copyright. So, gloss over the 3 projects if
>> you want to, and then I think I should add a tag like "ip-clearance",
>> and the more official review could be started. Or something like
>> that... Please advise!
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>>
>>
>> ===8<===End of original message text===
>>
>>
Re: AW: Using FreeMarkers Parser and Lexer
The solution for FTL would be quite similar to Javaparser: there should be *another* project that provides an FTL parser, but that's not (or not exactly) the same parser than that FTL uses internally, similarly to as Javaparser is not the same parser that javac uses internally. Maybe the best way of making a such parser is copying and then modifying the current parser, and ideally, that project is also helped by people who work on FreeMarker itself, so that new language features will get in, and test cases for new FTL features are provided. But someone had to take this quite big task on himself, with longer term maintenance ideally. Also, I think you will be better of by copying the current stuff into another package (maybe under a liberal license), than accessing things with reflection and such that was told to be internal. In the first case you might won't support the latest language features after a FreeMarker update, but at least your code won't die with ClassNotFound and NoSuchMethod after the same FreeMarker update. (To understand my standpoint more, my opinion is that one day, the current parser will have to be heavily reworked, together with some other internals. The goal of that is making the language more extensible and making templates more introspectable with public API-s. Another thing worths knowing is that keeping backward compatibility causes a lot of hardship for FM, partly because of API-s negligently exposed in the old days. So I have become very careful with undertaking new backward compatibility obligations.) -- Thanks, Daniel Dekany Saturday, September 12, 2015, 3:24:08 PM, Malte Brunnlieb wrote: > Hi, > > I am currently trying to work with the Lexer/Parser of FreeMarker as well as > the Lexer/Parser of the target language to support syntax-safe generation. > Thus, it would be nice to just use the FreeMarker library to parse > FreeMarker templates as it is also possible with the javaparser I am using. > > I respect the idea of only providing APIs, which will be backward compatible > in future. Nevertheless, The TokenManager as well as the Parser do follow a > commonly used API Pattern, which should be quite stable and could be made > accessible. I do not claim to support these APIs actively by providing any > documentation. It just makes life easier for those, who want to provide > further tool support for FreeMarker template editors as well as further > language engineers trying to use or adapt FreeMarker as a meta-language for > any (possibly research) intention. Providing the lexer and parser with your > deployment for free eventually would establish FreeMarker even more due to > more potential tool support. > > Currently, I somehow managed to work with the non-public TokenManager and > Parser API by hacking accessibility via reflection. > I know this is not a stable approach, but I am fine with it to just get the > lexer token stream and the parser token stream to work on further ideas. > > Best Regards, > Malte > > -Ursprüngliche Nachricht- > Von: Daniel Dekany [mailto:ddek...@freemail.hu] > Gesendet: Freitag, 11. September 2015 17:53 > An: Malte Brunnlieb > Betreff: Re: Using FreeMarkers Parser and Lexer > > That the related API-s are not public or are public but marked as > internal/deprecated is because FM doesn't provide backward compatibility > there. So you might as well copy them into your package and change the > visibilities, etc. > > What exactly do you want to achieve? > > > Thursday, September 10, 2015, 11:33:42 AM, Malte Brunnlieb wrote: > >> Hi all, >> >> due to my current research, I try to access FreeMarkers Parser and/or >> Lexer appropriately, but it seems, that you have already successfully >> hidden the most necessary classes to do so. >> The only thing, I am currently able to do is to get the parsed element >> root. Nevertheless, also this API seems to be deprecated. >> >> I also tried to work directly with the FTL.jj defintion, but you >> adapted the API of the Parser and Lexer Exceptions I cannot simply >> reuse from your library. >> >> I know that my issue is a very special and advanced use case, but do >> you see any possibility to work with the latest FreeMarker >> Lexer/Parser by simple library reuse? >> >> Best Regards, >> Malte >> >> > > -- > Thanks, > Daniel Dekany
[VOTE] Proposal: Extended decimal fomat strings
Because not many people are here yet, it will be lazy vote. Is that
OK? 72 hours to go, unless there will be an active discussion of
course.
We had some RFE-s in past, where someone requested:
- Using half-up rounding mode instead of the Java default half-even
(https://sourceforge.net/p/freemarker/feature-requests/62/)
- Overriding the symbol used for NaN
(https://sourceforge.net/p/freemarker/feature-requests/67/)
- Using dot as decimal separator for certain numbers, instead of
the locale default (which was comma there) (but not the case of ?c)
(https://sourceforge.net/p/freemarker/feature-requests/117/)
I remember some other case (maybe it was just e-mail) where the user
has complained that in general he can't use all the features of
java.text.DecimalFormat as we only allow specifying the pattern
string.
The number format is specified with a string in FreeMarker. This is so
in the Configurable API, also in FTL (<#setting number_format="0.##">
and n?string("0.##")). So I wondered how to allow specifying the
parameters for DecimalFormat without making a mess, and found that we
can just extend the string parsed by DecimalFormat with a new section,
that would cause IllegalArgumentException if you pass it to
DecimalFormat as is, so it's backward compatible to add such a
section.
DecimalFormat accepts almost all kind of random string without
complaining. But it's string about ';'. DecmialFormat allows you to
specify two patterns, one for the positive, and another for the
negative numbers, separated by ';'. We could allow yet another ';' and
a further section, where the properties of the Decimal format can be
specified. So if someone wants '_' for grouping separator and half-up
rounding mode, then instead of ",##0.##", he could use ",##0.##;;
grp=_ ro=hu". The double ";;" is because the 2nd section (for negative
number format) is empty. (This is backward compatible, as that's an
error for pure DecimalFormat.) In general, the 3rd section will be a
list of key=value pairs separated by whitespace and and optional
comma. If a value needs quoting, the quotation rules of DecimalFormat
patterns will be used (i.e, use apostrophe-quote, and double it for
escaping). The allowed keys would be:
- ro=u|d|c|f|hu|hd|he|un: RoundingMode
- mul: Multipier
- dec: DecimalSeparator
- grp: GroupingSeparator
- exp: ExponentSeparator
- min: MinusSign
- inf: Infinity
- nan: NaN
- prc: Percent
- prm: PerMill
- zero: ZeroDigit
- curc: Currency (ISO 4217 Code)
- curs: CurrencySymbol 2nd
- icurs: InternationalCurrencySymbol
- mdec: MonetaryDecimalSeparator
I will add this feature, if you agree.
--
Thanks,
Daniel Dekany
Re: [Freemarker-devel] [VOTE] Proposal: Extended decimal fomat strings
Sunday, September 13, 2015, 4:45:32 PM, brede...@me.com wrote:
> I vote for the number format extension.
Thanks, and that would be "+1 (non-binding)" according the Apache
voting rules. ("Non-binding" because you aren't PMC member...
formality. BTW, if you want to be a PMC member, I'm open to that.)
> Note that this may not be forward compatible with future versions
> of the Java library, since Oracle could well have just the same idea.
Good point. Actually it's forward compatible as FreeMarker will
continue handling that section even then, but I see what you mean. So
either we take this small(?) risk, or we do something like "0.##;;
#ext grp=_ ro=hu", which looks less tidy.
> I suggest the keys are open for discussion; I am not sure "ro" for
> rounding mode is very clear for example.
Yes, that's questionable. What do others think?
My thinking was that people often specify the formatting ad-hoc, like
${n?string('0.00;;ro=hu')}, and then
${n?string('0.00;;roundig=half-up')} is perhaps too verbose. OTOH I
never liked these ad-hoc patterns in the templates, and that's one
reason why in 2.3.24 you can define a custom format, let's call it
"weight", as the alias of and other format string (like of "0.##"
etc.) in Configuration and/or Template and/or Environment, and then in
the template use ${n?string.@weight}. If users will adopt this
approach, then '0.00;;roundig=half-up' is a clear winner. Otherwise
I'm not sure.
> Also how do you decide if the currency symbol is before or after the
> number?
The place of currency symbol is specified in the standard
DecimalFormat pattern with a "¤" (\u00A4) or "¤¤". In the extension
part we just allow overriding how it looks, not where it is.
P.S. I still post these mails on both dev lists, but who is still only
on freemarker-de...@lists.sourceforge.net, please click on
dev-subscr...@freemarker.incubator.apache.org!
--
Thanks,
Daniel Dekany
> Cheers,
>
> -- Denis.
> Original Message
> From: Daniel Dekany
> Sent: Sunday, 13 September 2015 12:20
> To: dev@freemarker.incubator.apache.org
> Reply To: Daniel Dekany
> Cc: freemarker-de...@lists.sourceforge.net
> Subject: [Freemarker-devel] [VOTE] Proposal: Extended decimal fomat strings
>
> Because not many people are here yet, it will be lazy vote. Is that
> OK? 72 hours to go, unless there will be an active discussion of
> course.
>
> We had some RFE-s in past, where someone requested:
> - Using half-up rounding mode instead of the Java default half-even
> (https://sourceforge.net/p/freemarker/feature-requests/62/)
> - Overriding the symbol used for NaN
> (https://sourceforge.net/p/freemarker/feature-requests/67/)
> - Using dot as decimal separator for certain numbers, instead of
> the locale default (which was comma there) (but not the case of ?c)
> (https://sourceforge.net/p/freemarker/feature-requests/117/)
>
> I remember some other case (maybe it was just e-mail) where the user
> has complained that in general he can't use all the features of
> java.text.DecimalFormat as we only allow specifying the pattern
> string.
>
> The number format is specified with a string in FreeMarker. This is so
> in the Configurable API, also in FTL (<#setting number_format="0.##">
> and n?string("0.##")). So I wondered how to allow specifying the
> parameters for DecimalFormat without making a mess, and found that we
> can just extend the string parsed by DecimalFormat with a new section,
> that would cause IllegalArgumentException if you pass it to
> DecimalFormat as is, so it's backward compatible to add such a
> section.
>
> DecimalFormat accepts almost all kind of random string without
> complaining. But it's string about ';'. DecmialFormat allows you to
> specify two patterns, one for the positive, and another for the
> negative numbers, separated by ';'. We could allow yet another ';' and
> a further section, where the properties of the Decimal format can be
> specified. So if someone wants '_' for grouping separator and half-up
> rounding mode, then instead of ",##0.##", he could use ",##0.##;;
> grp=_ ro=hu". The double ";;" is because the 2nd section (for negative
> number format) is empty. (This is backward compatible, as that's an
> error for pure DecimalFormat.) In general, the 3rd section will be a
> list of key=value pairs separated by whitespace and and optional
> comma. If a value needs quoting, the quotation rules of DecimalFormat
> patterns will be used (i.e, use apostrophe-quote, and double it for
> escaping). The allowed keys would be:
>
> - ro=u|d|c|f|hu|hd|he|un: RoundingMode
> - mul: Multipier
> - dec: DecimalSeparator
> - grp: GroupingSeparator
> - exp: ExponentSeparator
> - min: MinusSign
> - inf: Infinity
> - nan: NaN
> - prc: Percent
> - prm: PerMill
> - zero: ZeroDigit
> - curc: Currency (ISO 4217 Code)
> - curs: CurrencySymbol 2nd
> - icurs: InternationalCurrencySymbol
> - mdec: MonetaryDecimalSeparator
>
> I will add this feature, if you agree.
>
Re: Rest Service for FreeMarkerOnline
The copyright header is missing in FreeMarkerOnlineExecuteResource and FreeMarkerOnlineExecuteResourceTest, maybe somewhere else too. Also, it's not a blocker, but if it's possible to solve that the blocker plugin starts the darkening effect a bit later, like after a 1 seconds or so (see earlier mail why), that would be good IMO. So after fixing the copyrights, I say, let's push it. In the push message describe clearly the purpose of it of course (AJAX instead of full-page-refresh, among others so that Ctrl+Z works in the text areas after submitting), and mention that I have agreed with this change. As of the removed tests, that we don't AJAX-post with Selenium is OK (I guess), but the initial page visiting could be still covered, also the case where we POST the template + dataModel with the initial non-AJAX request. Of course that can be addressed after pushing too, as with the current 85% test coverage I think we pass. Last not least, thank you for the work you have done so far! -- Thanks, Daniel Dekany Sunday, September 13, 2015, 5:23:41 PM, Pradeep Murugesan wrote: > Hi Daniel, > Sorry just noticed didn't leave a space between 2 commits. > https://github.com/pradeepmurugesan/freemarker-online/commit/fe73e33bfcc7ab964972e7251d9d05c282acb890 > https://github.com/pradeepmurugesan/freemarker-online/commit/d44a37a3d5f185a64c64d8a8a10602cee67ad2db > Got a chance to review the same. > Pradeep. > P.S: Mistakenly sent an incomplete message previously. > >> From: pradeepmuruge...@outlook.com >> To: dev@freemarker.incubator.apache.org >> Subject: RE: Rest Service for FreeMarkerOnline >> Date: Sat, 12 Sep 2015 14:19:16 +0530 >> >> Hi Daniel, >> I tried to work on the Webdriver Test , it works on a Chrome Driver but >> fails on this Headless browser driver HTMLUnitTestDriver. >> I couldn't fix the same. For now I am removing that particular test. >> https://github.com/pradeepmurugesan/freemarker-online/commit/fe73e33bfcc7ab964972e7251d9d05c282acb890https://github.com/pradeepmurugesan/freemarker-online/commit/d44a37a3d5f185a64c64d8a8a10602cee67ad2db >> >> Please review it once. If we are good to go , I will issue a PR. >> Pradeep. >> > Date: Fri, 11 Sep 2015 18:41:25 +0200 >> > From: ddek...@freemail.hu >> > To: dev@freemarker.incubator.apache.org >> > Subject: Re: Rest Service for FreeMarkerOnline >> > >> > Friday, September 11, 2015, 1:30:27 PM, Pradeep Murugesan wrote: >> > >> > > Hi Daniel, >> > > >> > > Have fixed things. Except for the following >> > > 1. All the old non-AJAX code can be removed now I thought >> > > we would be needing this when we try to connect FM-online from user >> > > manual. >> > >> > You meant the examples in the manual would do a HTTP POST that >> > immediately run the code. I think you are right, that would be better >> > then filling the form with a POST, and then starting an AJAX request. >> > However, the amount of code duplication should minimized (if it >> > wasn't). Also we will need a test just for this case. >> > >> > > 2. Regarding the Ajax spinner I have used the blockUI library >> > > http://malsup.com/jquery/block/. Let me know if we need to change this. >> > >> > I think it will be good, because it only starts to change the screen >> > after a while, so for fast executions you see no flashing or such. >> > Certainly it need to be adjusted though, as the on-line service >> > certainly won't respond that fast, so the darkening will be started >> > too early. >> > >> > > 3. Web driver test - I am trying to make it work. >> > >> > I suspect the selenium thing will only cover the initial POST (the >> > Manual use case). >> > >> > When the JUnit coverage is good enough, I think you should make a pull >> > request. (Tell me when you are about doing that, so that I can check >> > the thing for the last time.) >> > >> > > Others , I have fixed and pushed. >> > > https://github.com/pradeepmurugesan/freemarker-online/commit/22e310f7112ce28c470e162893984940b720c8c0 >> > > >> > > Pradeep. >> > >> Date: Mon, 7 Sep 2015 23:32:01 +0200 >> > >> From: ddek...@freemail.hu >> > >> To: dev@freemarker.incubator.apache.org >> > >> Subject: Re: Rest Service for FreeMarkerOnline >> > >> >> > >> I have looked at it now. I haven't seen any big issues. I ran into >> > >> small t
Re: AW: AW: Using FreeMarkers Parser and Lexer
Sunday, September 13, 2015, 1:15:05 PM, Malte Brunnlieb wrote:
> Hi Daniel,
>
> I try to transform the FreeMarker javaCC grammar to an ANTLR4 grammar.
> I did not get the sematics of this lexer state syntax:
>
> SKIP :
> {
> ...
> }
>
> What does this mean?
The stuff inside <...> means that the patterns inside the {...} are
only used in the lexical states listed there (logical "or").
> Does this match the current stack of lexer states? Does JavaCC
> manage lexer states in a stack anyhow?
At any moment the lexer is in a single state which is identified with
a name (initially DEFAULT), and that's only what it matches. There's
no stack as far as I know. The regular expressions switch between
states directly.
> I googled a lot but could not find this syntax in the web.
> If so, how to push/pop something from the lexer stack in javaCC?
One could maintain a such stack manually, since you can have custom
lexer state fields. It doesn't solve matching against stack content
efficiently, but at least you can push and pop, with your own methods.
> I just could find the swithTo(...) trigger.
>
> Best Regards,
> Malte
>
> -Ursprüngliche Nachricht-
> Von: Daniel Dekany [mailto:ddek...@freemail.hu]
> Gesendet: Samstag, 12. September 2015 19:40
> An: Malte Brunnlieb
> Cc: dev@freemarker.incubator.apache.org
> Betreff: Re: AW: Using FreeMarkers Parser and Lexer
>
> The solution for FTL would be quite similar to Javaparser: there should be
> *another* project that provides an FTL parser, but that's not (or not
> exactly) the same parser than that FTL uses internally, similarly to as
> Javaparser is not the same parser that javac uses internally. Maybe the best
> way of making a such parser is copying and then modifying the current
> parser, and ideally, that project is also helped by people who work on
> FreeMarker itself, so that new language features will get in, and test cases
> for new FTL features are provided. But someone had to take this quite big
> task on himself, with longer term maintenance ideally.
>
> Also, I think you will be better of by copying the current stuff into
> another package (maybe under a liberal license), than accessing things with
> reflection and such that was told to be internal. In the first case you
> might won't support the latest language features after a FreeMarker update,
> but at least your code won't die with ClassNotFound and NoSuchMethod after
> the same FreeMarker update.
>
> (To understand my standpoint more, my opinion is that one day, the current
> parser will have to be heavily reworked, together with some other internals.
> The goal of that is making the language more extensible and making templates
> more introspectable with public API-s.
> Another thing worths knowing is that keeping backward compatibility causes a
> lot of hardship for FM, partly because of API-s negligently exposed in the
> old days. So I have become very careful with undertaking new backward
> compatibility obligations.)
>
> --
> Thanks,
> Daniel Dekany
>
>
> Saturday, September 12, 2015, 3:24:08 PM, Malte Brunnlieb wrote:
>
>> Hi,
>>
>> I am currently trying to work with the Lexer/Parser of FreeMarker as well
> as
>> the Lexer/Parser of the target language to support syntax-safe generation.
>> Thus, it would be nice to just use the FreeMarker library to parse
>> FreeMarker templates as it is also possible with the javaparser I am
> using.
>>
>> I respect the idea of only providing APIs, which will be backward
> compatible
>> in future. Nevertheless, The TokenManager as well as the Parser do follow
> a
>> commonly used API Pattern, which should be quite stable and could be made
>> accessible. I do not claim to support these APIs actively by providing any
>> documentation. It just makes life easier for those, who want to provide
>> further tool support for FreeMarker template editors as well as further
>> language engineers trying to use or adapt FreeMarker as a meta-language
> for
>> any (possibly research) intention. Providing the lexer and parser with
> your
>> deployment for free eventually would establish FreeMarker even more due to
>> more potential tool support.
>>
>> Currently, I somehow managed to work with the non-public TokenManager and
>> Parser API by hacking accessibility via reflection.
>> I know this is not a stable approach, but I am fine with it to just get
> the
>> lexer token stream and the parser token stream to work on further ideas.
>>
>> Best Regards,
>> Malte
>>
>> -Ursprüngliche Nachricht-
>> Von: Daniel Dekany [mailto:ddek...@freem
[VOTE] Drop JSP 1.2 support in 2.3.24
Yet another voting with lazy consensus... silence gives assent. 72 hours left. I think we have to drop JSP 1.2 support in 2.3.24 because of legal reasons. The jps-api 1.2 artifact can't be found in the Maven Central Repo, and it can't be upload for legal reasons. This means that as far as FreeMarker 2.3.x depends on it, it can't be built without developers getting that jar themselves and putting it into the Ivy cache or something. (It has worked so far because freemarker.org has hosted it in its own Ivy repo, but doing such legally gray things won't go anymore as we move the site to the ASF's infrastructure.) JSP 1.2 was part of J2EE 1.3 (September 24, 2001), and was replaced by JSP 2.0 in J2EE 1.4 (November 11, 2003). So hopefully not many users will be hurt. -- Thanks, Daniel Dekany
Re: FM-Online connect with Manual
Huh? I meant: ... Tuesday, September 15, 2015, 11:39:49 AM, Dékány Dániel wrote: > Won't something like method="post">... work? Anyway, I think both POST and GET > should do the same, but using POST should be the norm. With GET you > can get some very long URLs. While URL-s up to 2K length used to > work on most places, even URL-s over 256 bytes is sometimes considered > worrisome. > Pradeep Murugesan írta: >>Hi Daniel, >> The initial idea was when people click from manual we POST to the "/" with >> template and dataModel and get the page rendered directly. We do not have >> any direct method to open a new tab and directly post data. Some round about >> ways were mentioned in web but nothing concrete. >>So I thought of >>1. Issuing a GET request to fmonline/ with formdata. This will help us to >>populate the fields.2. We will also see if formdata is not empty then we will >>call our execute via ajax. 3. If formdata is empty we will know that its a >>normal GET request (i.e not from manual) and render the empty page. >> >>Let me know your thoughts. >>Pradeep. >> >> >> >> >> -- Thanks, Daniel Dekany
Re: FM-Online connect with Manual
I agree with what you have described. You have earlier said that this will work by first rendering the page with the filled form, and then sending the AJAX request. That's the most maintainable way of doing this, as it requires almost no duplicated functionality. So that's maybe fine. But the more efficient (lowest response time) way off doing this is also rendering the response together with the filled form, so there's no AJAX request. Wednesday, September 16, 2015, 7:05:58 AM, Pradeep Murugesan wrote: > Yeah I think the Cross Domain issues comes into play with > javascript. This approach should work. Let me do a POC and come back if its > not working. > Meanwhile please let me know if we have different visualizations. > Pradeep. > >> From: pradeepmuruge...@outlook.com >> To: dev@freemarker.incubator.apache.org >> Subject: RE: FM-Online connect with Manual >> Date: Wed, 16 Sep 2015 10:22:32 +0530 >> >> > ... >> Hmmm but the above code will be in our manual , we should get redirected to >> the FM-Online domain right. That's where I am doubting whether cross domain >> POST will be allowed through browser redirection. >> Ok Even before going there , Let me tell my understanding so that lets check >> if we are on the same page. >> 1. FM Manual website will have a button or a link saying "try it out" or >> something like that.2. When the user clicks on the same he will redirected >> to a new page(FM-Online) where the corresponding template and datamodel will >> be prefilled and executed. >> Am I right regarding this ? >> Kindly let me know if you have visualised something different ? >> Pradeep. >> >> > Date: Tue, 15 Sep 2015 22:39:21 +0200 >> > From: ddek...@freemail.hu >> > To: dev@freemarker.incubator.apache.org >> > Subject: Re: FM-Online connect with Manual >> > >> > Huh? I meant: >> > ... >> > >> > >> > Tuesday, September 15, 2015, 11:39:49 AM, Dékány Dániel wrote: >> > >> > > Won't something like > > > method="post">... work? Anyway, I think both POST and GET >> > > should do the same, but using POST should be the norm. With GET you >> > > can get some very long URLs. While URL-s up to 2K length used to >> > > work on most places, even URL-s over 256 bytes is sometimes considered >> > > worrisome. >> > > Pradeep Murugesan írta: >> > >>Hi Daniel, >> > >> The initial idea was when people click from manual we POST to the "/" >> > >> with template and dataModel and get the page rendered directly. We do >> > >> not have any direct method to open a new tab and directly post data. >> > >> Some round about ways were mentioned in web but nothing concrete. >> > >>So I thought of >> > >>1. Issuing a GET request to fmonline/ with formdata. This will help us >> > >>to populate the fields.2. We will also see if formdata is not empty then >> > >>we will call our execute via ajax. 3. If formdata is empty we will know >> > >>that its a normal GET request (i.e not from manual) and render the empty >> > >>page. >> > >> >> > >>Let me know your thoughts. >> > >>Pradeep. >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> > -- >> > Thanks, >> > Daniel Dekany >> > >> > -- Thanks, Daniel Dekany
Re: [VOTE] Proposal: Extended decimal fomat strings
The 72 hours for lazy-voting is almost out, and I only had input from
one person, and none from PMC members. Anyone wants to add anything?
This VOTE will decide if there will be DecimalFormat option
assignments after the 2nd ";", as it was proposed (find it quoted
below). Except, how exactly the parameter names will look (like "rnd"
VS "rounding") will be figured out afterwards.
BTW, I have renamed "ro" to "rnd", as that's more in line with "grp"
and such. OTOH it reads as "RaNDom" for most of us, so it's just
another compromise.
The original proposal:
> Because not many people are here yet, it will be lazy vote. Is that
> OK? 72 hours to go, unless there will be an active discussion of
> course.
>
> We had some RFE-s in past, where someone requested:
> - Using half-up rounding mode instead of the Java default half-even
> (https://sourceforge.net/p/freemarker/feature-requests/62/)
> - Overriding the symbol used for NaN
> (https://sourceforge.net/p/freemarker/feature-requests/67/)
> - Using dot as decimal separator for certain numbers, instead of
> the locale default (which was comma there) (but not the case of ?c)
> (https://sourceforge.net/p/freemarker/feature-requests/117/)
>
> I remember some other case (maybe it was just e-mail) where the user
> has complained that in general he can't use all the features of
> java.text.DecimalFormat as we only allow specifying the pattern
> string.
>
> The number format is specified with a string in FreeMarker. This is so
> in the Configurable API, also in FTL (<#setting number_format="0.##">
> and n?string("0.##")). So I wondered how to allow specifying the
> parameters for DecimalFormat without making a mess, and found that we
> can just extend the string parsed by DecimalFormat with a new section,
> that would cause IllegalArgumentException if you pass it to
> DecimalFormat as is, so it's backward compatible to add such a
> section.
>
> DecimalFormat accepts almost all kind of random string without
> complaining. But it's string about ';'. DecmialFormat allows you to
> specify two patterns, one for the positive, and another for the
> negative numbers, separated by ';'. We could allow yet another ';' and
> a further section, where the properties of the Decimal format can be
> specified. So if someone wants '_' for grouping separator and half-up
> rounding mode, then instead of ",##0.##", he could use ",##0.##;;
> grp=_ ro=hu". The double ";;" is because the 2nd section (for negative
> number format) is empty. (This is backward compatible, as that's an
> error for pure DecimalFormat.) In general, the 3rd section will be a
> list of key=value pairs separated by whitespace and and optional
> comma. If a value needs quoting, the quotation rules of DecimalFormat
> patterns will be used (i.e, use apostrophe-quote, and double it for
> escaping). The allowed keys would be:
>
> - ro=u|d|c|f|hu|hd|he|un: RoundingMode
> - mul: Multipier
> - dec: DecimalSeparator
> - grp: GroupingSeparator
> - exp: ExponentSeparator
> - min: MinusSign
> - inf: Infinity
> - nan: NaN
> - prc: Percent
> - prm: PerMill
> - zero: ZeroDigit
> - curc: Currency (ISO 4217 Code)
> - curs: CurrencySymbol 2nd
> - icurs: InternationalCurrencySymbol
> - mdec: MonetaryDecimalSeparator
>
> I will add this feature, if you agree.
--
Thanks,
Daniel Dekany
Re: [Freemarker-devel] [VOTE] Proposal: Extended decimal fomat strings
Wednesday, September 16, 2015, 6:53:39 PM, Evangelia Dendramis wrote:
> Seems like an OK feature. +1.
>
> I would like to note that as a front-end I've never needed that
> level of flexibility for decimals since that logic has always been
> handled in the backend.
Yes, ideally, the number formats are set in the backend. But how did
you do that? People usually set the "number_format" setting in the
Configuration, but that has this limitation that you could only
specify the pattern part of DecimalFormat. Now you can use "extended
decimal format strings" there. (Plus, in 2.3.24, for a while, you can
also define logical number formats, like "price", "weight", etc., and
then in the template write ${latitude?string.@price} and such.)
> I've really only ever needed to manipulate the format for locales.
> That's not to say the feature wouldn't be useful for a numbers-heavy
> app, e.g. something finance or statistics related.
More flexible number and date formatting is a recurring request, so
it's clearly needed. The question is how to do it. Right now it's
extended DecimalFormat format strings, and the possibility of
registering custom formatters (so you need not use DecimalFormat or
SimpleDateFormat).
--
Thanks,
Daniel Dekany
Re: [Mentors] Project status page
I have realized that I can update it too... and so I did. -- Thanks, Daniel Dekany Thursday, September 3, 2015, 1:03:11 AM, Daniel Dekany wrote: > I guess http://incubator.apache.org/projects/freemarker.html need some > updating. (I'm not supposed to edit that, AFAIR.) > > Also, I will ask infra to direct commit messages to > notificati...@freemarker.incubator.apache.org (if you agree). >
Re: [VOTE] Drop JSP 1.2 support in 2.3.24
All right, JSP 1.2 support was removed then, with lazy voting. There was no objection, and two +1-s outside of mine. (With this, the build no longer depends on any artifacts hosted on freemarker.org's Ivy repository.) Tuesday, September 15, 2015, 10:21:37 PM, Woonsan Ko wrote: > +1 > > Woonsan > > > On Mon, Sep 14, 2015 at 2:10 PM, Daniel Dekany wrote: >> Yet another voting with lazy consensus... silence gives assent. 72 >> hours left. >> >> I think we have to drop JSP 1.2 support in 2.3.24 because of legal >> reasons. The jps-api 1.2 artifact can't be found in the Maven Central >> Repo, and it can't be upload for legal reasons. This means that as far >> as FreeMarker 2.3.x depends on it, it can't be built without >> developers getting that jar themselves and putting it into the Ivy >> cache or something. (It has worked so far because freemarker.org has >> hosted it in its own Ivy repo, but doing such legally gray things >> won't go anymore as we move the site to the ASF's infrastructure.) >> >> JSP 1.2 was part of J2EE 1.3 (September 24, 2001), and was replaced by >> JSP 2.0 in J2EE 1.4 (November 11, 2003). So hopefully not many users >> will be hurt. >> >> -- >> Thanks, >> Daniel Dekany >> > -- Thanks, Daniel Dekany
Re: [Mentors] Starting IP clearance process?
I also hope that there's no much to do at this point, however, my
understanding was that clearance has to be voted:
http://incubator.apache.org/guides/mentor.html#poding-ip-clearance
BTW, at the end of September, I hope to be able to do
2.3.24-RC1-incubating at last, and I hope there will be no
bureaucratic obstacles. Let me know if any of you know of any!
--
Thanks,
Daniel Dekany
Sunday, September 20, 2015, 5:14:17 PM, Jacopo Cappellato wrote:
> Daniel,
>
> I think we are done with the IP clearance process at this point,
> the required CLAs and SFAs are all filed.
>
> Kind regards,
>
> Jacopo
>
> References:
> http://incubator.apache.org/guides/mentor.html#initial-clean-up
> http://incubator.apache.org/guides/mentor.html#initial-ip-clearance
>
>
> On Sep 12, 2015, at 3:31 PM, Daniel Dekany wrote:
>
>> Saturday, September 12, 2015, 10:49:37 AM, Sergio Fernández wrote:
>>
>>> Daniel, sorry, I'll try to go through this on Monday.
>>>
>>> For provenance purposes what it's important is to have tagged in both repos
>>> (original and asf) the concrete version that has been donated.
>>
>> I have added "donated-to-asf" tags in both the GitHub and ASF repos.
>> More precisely, as the "freemarker" repository (as opposed to the
>> "site" and "docgen" repos) has 3 branches ("2.3-gae", "2.3" and
>> "master"), there we have "2.3-gae-donated-to-asf" and
>> "2.3-donated-to-asf" and "master-donated-to-asf", respectively.
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>>> On Sep 12, 2015 10:02 AM, "Daniel Dekany" wrote:
>>>
>>>> Just wanted to bring the below mail to your attention, as it was now 9
>>>> days without any reaction.
>>>>
>>>>
>>>> This is a forwarded message
>>>> From: Daniel Dekany
>>>> To: dev@freemarker.incubator.apache.org
>>>> Date: Thursday, September 3, 2015, 12:56:50 AM
>>>> Subject: [Mentors] Starting IP clearance process?
>>>>
>>>> ===8<==Original message text===
>>>> Dear Mentors (and others who want to help),
>>>>
>>>> We have the 3 repos (freemarker, docgen, site) imported as you might
>>>> noticed from the flood of commit messages (sorry...), and I have
>>>> changed the copyright headers, ensured that the 3 standard legal files
>>>> (NOTICE, LICENSE and DISCLAIMER) are there, and removed files that I
>>>> have spotted with unclear copyright. So, gloss over the 3 projects if
>>>> you want to, and then I think I should add a tag like "ip-clearance",
>>>> and the more official review could be started. Or something like
>>>> that... Please advise!
>>>>
>>>> --
>>>> Thanks,
>>>> Daniel Dekany
>>>>
>>>>
>>>>
>>>> ===8<===End of original message text===
>>>>
>>>>
>>
>
>
Re: [Mentors] Starting IP clearance process?
OK. If it's good enough for ASF, it's surely good for me.
(What will bit a bit funny though, is that in the last monthly report
I have stated that we are starting the IP clearance soon, also some
PPMC members have signed that. Now it turns out that it was already
done... Whatever.)
--
Thanks,
Daniel Dekany
Monday, September 21, 2015, 9:43:54 AM, Jacopo Cappellato wrote:
>
> On Sep 20, 2015, at 6:09 PM, Daniel Dekany wrote:
>
>> I also hope that there's no much to do at this point, however, my
>> understanding was that clearance has to be voted:
>> http://incubator.apache.org/guides/mentor.html#poding-ip-clearance
>
> I am saying we are done because of the following document
> (referenced by the document you mention above):
>
> http://incubator.apache.org/ip-clearance/index.html
>
> and specifically:
>
> "This form is not for new projects. This is for projects and PMCs
> that have already been created and are receiving a code donation into an
> existing codebase."
>
> This also adds some interesting details:
>
> http://incubator.apache.org/guides/mentor.html#initial-ip-clearance
>
> quoting:
>
> "Existing codebases need to be imported through the standard IP
> clearance process. This means that a Software Grant Agreement (SGA)
> or Contributor License Agreement (CLA) need to be submitted for all
> copyright owners. This process may take a while so it is best to
> start as soon as the podling is accepted. The acceptance of the
> initial codebases is approved by the IPMC as part of the acceptance
> motion. So, no vote is required by the PPMC."
>
>>
>> BTW, at the end of September, I hope to be able to do
>> 2.3.24-RC1-incubating at last, and I hope there will be no
>> bureaucratic obstacles. Let me know if any of you know of any!
>
> I don't. A tool that is useful to prepare and audit the release is the
> following:
>
> http://creadur.apache.org/rat/
>
> Regards,
>
> Jacopo
>
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>>
>> Sunday, September 20, 2015, 5:14:17 PM, Jacopo Cappellato wrote:
>>
>>> Daniel,
>>>
>>> I think we are done with the IP clearance process at this point,
>>> the required CLAs and SFAs are all filed.
>>>
>>> Kind regards,
>>>
>>> Jacopo
>>>
>>> References:
>>> http://incubator.apache.org/guides/mentor.html#initial-clean-up
>>> http://incubator.apache.org/guides/mentor.html#initial-ip-clearance
>>>
>>>
>>> On Sep 12, 2015, at 3:31 PM, Daniel Dekany wrote:
>>>
>>>> Saturday, September 12, 2015, 10:49:37 AM, Sergio Fernández wrote:
>>>>
>>>>> Daniel, sorry, I'll try to go through this on Monday.
>>>>>
>>>>> For provenance purposes what it's important is to have tagged in both
>>>>> repos
>>>>> (original and asf) the concrete version that has been donated.
>>>>
>>>> I have added "donated-to-asf" tags in both the GitHub and ASF repos.
>>>> More precisely, as the "freemarker" repository (as opposed to the
>>>> "site" and "docgen" repos) has 3 branches ("2.3-gae", "2.3" and
>>>> "master"), there we have "2.3-gae-donated-to-asf" and
>>>> "2.3-donated-to-asf" and "master-donated-to-asf", respectively.
>>>>
>>>> --
>>>> Thanks,
>>>> Daniel Dekany
>>>>
>>>>> On Sep 12, 2015 10:02 AM, "Daniel Dekany" wrote:
>>>>>
>>>>>> Just wanted to bring the below mail to your attention, as it was now 9
>>>>>> days without any reaction.
>>>>>>
>>>>>>
>>>>>> This is a forwarded message
>>>>>> From: Daniel Dekany
>>>>>> To: dev@freemarker.incubator.apache.org
>>>>>> Date: Thursday, September 3, 2015, 12:56:50 AM
>>>>>> Subject: [Mentors] Starting IP clearance process?
>>>>>>
>>>>>> ===8<==Original message text===
>>>>>> Dear Mentors (and others who want to help),
>>>>>>
>>>>>> We have the 3 repos (freemarker, docgen, site) imported as you might
>>>>>> noticed from the flood of commit messages (sorry...), and I have
>>>>>> changed the copyright headers, ensured that the 3 standard legal files
>>>>>> (NOTICE, LICENSE and DISCLAIMER) are there, and removed files that I
>>>>>> have spotted with unclear copyright. So, gloss over the 3 projects if
>>>>>> you want to, and then I think I should add a tag like "ip-clearance",
>>>>>> and the more official review could be started. Or something like
>>>>>> that... Please advise!
>>>>>>
>>>>>> --
>>>>>> Thanks,
>>>>>> Daniel Dekany
>>>>>>
>>>>>>
>>>>>>
>>>>>> ===8<===End of original message text===
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>
>
>
Re: FM-Online connect with Manual
Sorry... it was in the back of my head, but now... I see no fundamental problem with it. Some minor notices: I think it's unnecessary to move the immediate execution functionality out to js/execute.js, especially as there's many other "ready" functionality just bellow it, inside that "script" element directly. It could fit on there. Also I guess it would be more reliable if the immediate execution action is the last among the "ready" actions, because that's when it happens in the normal (non-Manual) case too. Some JavaDoc about FreeMarkerOnlineView constuctor paramteters, especially about `execute` wouldn't hurt at this point. I see your pull request is still pending... Well, after 14 days or so I will start asking about it. Also when this current thing is ready, push it too. And yes, you in general you are supposed to work in feature branches and push those, otherwise you append to the last "master" push. However, I say, this current work can be appended to it, as they aren't really separate features. -- Thanks, Daniel Dekany Monday, September 21, 2015, 7:43:08 PM, Pradeep Murugesan wrote: > Daniel, > got a chance to review the changes ? > Pradeep. > >> From: pradeepmuruge...@outlook.com >> To: dev@freemarker.incubator.apache.org >> Subject: RE: FM-Online connect with Manual >> Date: Sat, 19 Sep 2015 22:52:11 +0530 >> >> Hi Daniel, >> the POC worked. So I have made the changes to suit our idea of triggering >> Ajax when we click from manual. >> I have removed the non ajax code and also modified the unit test cases. >> Removed a file that is not used after the changes. >> https://github.com/pradeepmurugesan/freemarker-online/commit/d90745d91d94503f444fab8ac41d8a0443ac5794 >> https://github.com/pradeepmurugesan/freemarker-online/commit/546a73cb4476a8b981858825c907704ece36973d >> I have checked these into another branch(FreeMarker_Manual_Try_it_out) since >> the first pull request is not accepted by them yet and I am not sure If I >> push these changes it will go as part of existing pull request. >> Kindly review and let me know if any changes. >> Pradeep. >> >> > Date: Wed, 16 Sep 2015 08:39:36 +0200 >> > From: ddek...@freemail.hu >> > To: dev@freemarker.incubator.apache.org >> > Subject: Re: FM-Online connect with Manual >> > >> > I agree with what you have described. >> > >> > You have earlier said that this will work by first rendering the page >> > with the filled form, and then sending the AJAX request. That's the >> > most maintainable way of doing this, as it requires almost no >> > duplicated functionality. So that's maybe fine. But the more efficient >> > (lowest response time) way off doing this is also rendering the >> > response together with the filled form, so there's no AJAX request. >> > >> > >> > Wednesday, September 16, 2015, 7:05:58 AM, Pradeep Murugesan wrote: >> > >> > > Yeah I think the Cross Domain issues comes into play with >> > > javascript. This approach should work. Let me do a POC and come back if >> > > its not working. >> > > Meanwhile please let me know if we have different visualizations. >> > > Pradeep. >> > > >> > >> From: pradeepmuruge...@outlook.com >> > >> To: dev@freemarker.incubator.apache.org >> > >> Subject: RE: FM-Online connect with Manual >> > >> Date: Wed, 16 Sep 2015 10:22:32 +0530 >> > >> >> > >> > ... >> > >> Hmmm but the above code will be in our manual , we should get >> > >> redirected to the FM-Online domain right. That's where I am doubting >> > >> whether cross domain POST will be allowed through browser redirection. >> > >> Ok Even before going there , Let me tell my understanding so that lets >> > >> check if we are on the same page. >> > >> 1. FM Manual website will have a button or a link saying "try it out" >> > >> or something like that.2. When the user clicks on the same he will >> > >> redirected to a new page(FM-Online) where the corresponding template >> > >> and datamodel will be prefilled and executed. >> > >> Am I right regarding this ? >> > >> Kindly let me know if you have visualised something different ? >> > >> Pradeep. >> > >> >> > >> > Date: Tue, 15 Sep 2015 22:39:21 +0200 >> > >> > From: ddek...@freemail.hu >> > >> > To: de
Re: [VOTE] Drop JSP 1.2 support in 2.3.24
Tuesday, September 22, 2015, 4:49:25 PM, Ralph Goers wrote: > Sorry for being late to the party, but I just wanted to point out > that in case you aren’t aware votes are not required for these kinds > of things - you can simply start a discussion and see if anyone > objects. OK, thanks. > If someone wants to discuss it it can also get messy as you will mix > a bunch of discussion emails in your vote thread. Yes, if there's a bigger developer community, first discussion thread, then voting thread. > That said, there is nothing wrong with asking for a vote if you want > formal permission. > > Also - does FreeMarker follow Commit-Then-Review (CTR) or > Review-Then-Commit (RTC)? I am guessing CTR (which is my personal > preference) but a lot of the Hadoop-based projects have been using RTC with > reviewboard. If there will be more the one active committers who work on FreeMarker, then I will prefer people committing into their own feature branches, which will be merged if there's consensus and test coverage. (As far as there's only one active committer (me), there rules aren't defined much.) > Ralph > >> On Sep 14, 2015, at 11:10 AM, Daniel Dekany wrote: >> >> Yet another voting with lazy consensus... silence gives assent. 72 >> hours left. >> >> I think we have to drop JSP 1.2 support in 2.3.24 because of legal >> reasons. The jps-api 1.2 artifact can't be found in the Maven Central >> Repo, and it can't be upload for legal reasons. This means that as far >> as FreeMarker 2.3.x depends on it, it can't be built without >> developers getting that jar themselves and putting it into the Ivy >> cache or something. (It has worked so far because freemarker.org has >> hosted it in its own Ivy repo, but doing such legally gray things >> won't go anymore as we move the site to the ASF's infrastructure.) >> >> JSP 1.2 was part of J2EE 1.3 (September 24, 2001), and was replaced by >> JSP 2.0 in J2EE 1.4 (November 11, 2003). So hopefully not many users >> will be hurt. >> >> -- >> Thanks, >> Daniel Dekany >> >> > > > -- Thanks, Daniel Dekany
Re: Freemarker manual Local set up
The Manual is in the "freemarker" project, under src/manual. It also uses docgen of course. (You can download the latest docgen artifact with running `ant update-deps` in the "freemarker" project.) The manual is built with `ant manualOffline` or `manualFreemarkerOrg`. As of README-s, all 3 modules (freemarker, site, docgen) has one, so what's not described there is probably undocumented... Anyway, it's docgen's responsibility to generate the hidden HTML forms and JavaScript that will be needed. (Both the Web site and the Manual is built from DocBook XML by Docgen.) -- Thanks, Daniel Dekany Wednesday, September 23, 2015, 7:33:05 PM, Pradeep Murugesan wrote: > Hi Daniel, >I could see that freemarker manual is part of the site > http://freemarker.org/docs/index.html > Since that is generated using the doc-gen, I am trying to look into > the https://github.com/apache/incubator-freemarker-site for manual contents. > https://github.com/apache/incubator-freemarker-site/blob/master/src/main/docgen/book.xml > references to the site but I am not able to get the xml for manual which > doc-gen converts. > > I am trying to get the manual up and running locally to connect > with the freemarker online. Is there any readme kind of thing to achieve the > same ? > Please guide me. > Pradeep.
Re: FM-Online connect with Manual
OK, that's all fine. If you going to modify Docgen, you will need a CLA at ASF, if you don't yet have it. -- Thanks, Daniel Dekany Wednesday, September 23, 2015, 11:54:20 AM, Pradeep Murugesan wrote: > Hi Daniel, >> Date: Mon, 21 Sep 2015 21:01:25 +0200 >> From: ddek...@freemail.hu >> To: dev@freemarker.incubator.apache.org >> Subject: Re: FM-Online connect with Manual >> >> Sorry... it was in the back of my head, but now... >> >> I see no fundamental problem with it. Some minor notices: >> >> I think it's unnecessary to move the immediate execution functionality >> out to js/execute.js, especially as there's many other "ready" >> functionality just bellow it, inside that "script" element directly. >> It could fit on there. >> > Yeah I moved it over there >> Also I guess it would be more reliable if the immediate execution >> action is the last among the "ready" actions, because that's when it >> happens in the normal (non-Manual) case too. >> > Yeah Non-Manual, we don't this since the button click will trigger the same. >> Some JavaDoc about FreeMarkerOnlineView constuctor paramteters, >> especially about `execute` wouldn't hurt at this point. >> > I have added the doc. added description only for execute since I > feel other params are explicit. Let me know If i need to add for the other 2 > as well. >> I see your pull request is still pending... Well, after 14 days or so >> I will start asking about it. Also when this current thing is ready, >> push it too. >> >> And yes, you in general you are supposed to work in feature branches >> and push those, otherwise you append to the last "master" push. >> However, I say, this current work can be appended to it, as they >> aren't really separate features. >> > I have added to the same pull request. > Pradeep. >> -- >> Thanks, >> Daniel Dekany >> >> >> Monday, September 21, 2015, 7:43:08 PM, Pradeep Murugesan wrote: >> >> > Daniel, >> > got a chance to review the changes ? >> > Pradeep. >> > >> >> From: pradeepmuruge...@outlook.com >> >> To: dev@freemarker.incubator.apache.org >> >> Subject: RE: FM-Online connect with Manual >> >> Date: Sat, 19 Sep 2015 22:52:11 +0530 >> >> >> >> Hi Daniel, >> >> the POC worked. So I have made the changes to suit our idea of >> >> triggering Ajax when we click from manual. >> >> I have removed the non ajax code and also modified the unit test cases. >> >> Removed a file that is not used after the changes. >> >> https://github.com/pradeepmurugesan/freemarker-online/commit/d90745d91d94503f444fab8ac41d8a0443ac5794 >> >> https://github.com/pradeepmurugesan/freemarker-online/commit/546a73cb4476a8b981858825c907704ece36973d >> >> I have checked these into another branch(FreeMarker_Manual_Try_it_out) >> >> since the first pull request is not accepted by them yet and I am not >> >> sure If I push these changes it will go as part of existing pull request. >> >> Kindly review and let me know if any changes. >> >> Pradeep. >> >> >> >> > Date: Wed, 16 Sep 2015 08:39:36 +0200 >> >> > From: ddek...@freemail.hu >> >> > To: dev@freemarker.incubator.apache.org >> >> > Subject: Re: FM-Online connect with Manual >> >> > >> >> > I agree with what you have described. >> >> > >> >> > You have earlier said that this will work by first rendering the page >> >> > with the filled form, and then sending the AJAX request. That's the >> >> > most maintainable way of doing this, as it requires almost no >> >> > duplicated functionality. So that's maybe fine. But the more efficient >> >> > (lowest response time) way off doing this is also rendering the >> >> > response together with the filled form, so there's no AJAX request. >> >> > >> >> > >> >> > Wednesday, September 16, 2015, 7:05:58 AM, Pradeep Murugesan wrote: >> >> > >> >> > > Yeah I think the Cross Domain issues comes into play with >> >> > > javascript. This approach should work. Let me do a POC and come back >> >> > > if its not working. >> >> > > Meanwhile please let me know if we have different visualizations. >> >> > > Pradeep. >>
Option names in extended DecimalFormat format strings
Earlier I have talked (and held a vote) about extended format strings,
but as reminder, for a while in 2.3.24 nightly you can do things like
this:
${n?string("#.00;; rnd=hu inf='∞'")}
or set the number_format setting to something like that. The thing to
note is the section after the 2nd ";", which is not allowed be
DecimalFormat (as it only supports two sections), it's an extension by
FreeMarker.
How should the option names look? Like instead of the current
abbreviated form, it could be like "#.00;; rounding='half-up'
infinity='∞'" too. Currently it's like below. Opinions?
rnd
Rounding mode. The value is one of u for up, d for down, c for
ceiling, f for floor, hu for half-up, hd for half-down, he for
half-even, and un for unused. (See the java.math.RoundingMode API
for explanations.)
mul
Multiplier. The number will be shown after multiplied with this
integer number.
dec
Decimal separator character (like "." in 3.14).
mdec
Monetary decimal separator character. This is used instead of dec
when the pattern contains parts that make it a monetary format. (See
the Java decimal number format documentation for more.)
grp
Grouping separator character. Note that grouping is turned on by
using "," in the patter, as shown in the earlier example. If it's
not turned on, this option won't have visible effect.
exp
Exponent separator string. Only has visible effect if the pattern
specifies exponential form, like "0.##E0".
min
Minus sign character.
inf
The string used to show infinity.
nan
The string used to show not-a-number (NaN).
prc
Percent character.
prm
Per-mill character.
zero
Zero character. This modifies the other digits too, for example, if
zero is A, then 1 will B, 2 will be C, and so on.
curc
Currency ISO 4217 code. Only has effect when the pattern contains
parts that make it a monetary format. It's an error to specify a
code that's not a known ISO 4217 code in the Java installation.
curs
Currency symbol; shown where the localized currency name is present
in the pattern. Overrides the symbol determined from curc.
--
Thanks,
Daniel Dekany
Re: FM-Online connect with Manual
Yes. (Note that ICLA is only sufficient if your employer can't claim that your work belong to them.) Thursday, September 24, 2015, 5:49:25 AM, Pradeep Murugesan wrote: > Sure Daniel, > http://www.apache.org/licenses/icla.pdf > Will it be sufficient to fill this copy scan and email to > secret...@apache.org as mentioned here > http://www.apache.org/licenses/#submitting ? > Pradeep. > >> Date: Wed, 23 Sep 2015 21:45:33 +0200 >> From: ddek...@freemail.hu >> To: dev@freemarker.incubator.apache.org >> Subject: Re: FM-Online connect with Manual >> >> OK, that's all fine. >> >> If you going to modify Docgen, you will need a CLA at ASF, if you >> don't yet have it. >> >> -- >> Thanks, >> Daniel Dekany >> >> >> Wednesday, September 23, 2015, 11:54:20 AM, Pradeep Murugesan wrote: >> >> > Hi Daniel, >> >> Date: Mon, 21 Sep 2015 21:01:25 +0200 >> >> From: ddek...@freemail.hu >> >> To: dev@freemarker.incubator.apache.org >> >> Subject: Re: FM-Online connect with Manual >> >> >> >> Sorry... it was in the back of my head, but now... >> >> >> >> I see no fundamental problem with it. Some minor notices: >> >> >> >> I think it's unnecessary to move the immediate execution functionality >> >> out to js/execute.js, especially as there's many other "ready" >> >> functionality just bellow it, inside that "script" element directly. >> >> It could fit on there. >> >> >> > Yeah I moved it over there >> >> Also I guess it would be more reliable if the immediate execution >> >> action is the last among the "ready" actions, because that's when it >> >> happens in the normal (non-Manual) case too. >> >> >> > Yeah Non-Manual, we don't this since the button click will trigger the >> > same. >> >> Some JavaDoc about FreeMarkerOnlineView constuctor paramteters, >> >> especially about `execute` wouldn't hurt at this point. >> >> >> > I have added the doc. added description only for execute since I >> > feel other params are explicit. Let me know If i need to add for the other >> > 2 as well. >> >> I see your pull request is still pending... Well, after 14 days or so >> >> I will start asking about it. Also when this current thing is ready, >> >> push it too. >> >> >> >> And yes, you in general you are supposed to work in feature branches >> >> and push those, otherwise you append to the last "master" push. >> >> However, I say, this current work can be appended to it, as they >> >> aren't really separate features. >> >> >> > I have added to the same pull request. >> > Pradeep. >> >> -- >> >> Thanks, >> >> Daniel Dekany >> >> >> >> >> >> Monday, September 21, 2015, 7:43:08 PM, Pradeep Murugesan wrote: >> >> >> >> > Daniel, >> >> > got a chance to review the changes ? >> >> > Pradeep. >> >> > >> >> >> From: pradeepmuruge...@outlook.com >> >> >> To: dev@freemarker.incubator.apache.org >> >> >> Subject: RE: FM-Online connect with Manual >> >> >> Date: Sat, 19 Sep 2015 22:52:11 +0530 >> >> >> >> >> >> Hi Daniel, >> >> >> the POC worked. So I have made the changes to suit our idea of >> >> >> triggering Ajax when we click from manual. >> >> >> I have removed the non ajax code and also modified the unit test >> >> >> cases. Removed a file that is not used after the changes. >> >> >> https://github.com/pradeepmurugesan/freemarker-online/commit/d90745d91d94503f444fab8ac41d8a0443ac5794 >> >> >> https://github.com/pradeepmurugesan/freemarker-online/commit/546a73cb4476a8b981858825c907704ece36973d >> >> >> I have checked these into another branch(FreeMarker_Manual_Try_it_out) >> >> >> since the first pull request is not accepted by them yet and I am not >> >> >> sure If I push these changes it will go as part of existing pull >> >> >> request. >> >> >> Kindly review and let me know if any changes. >> >> >> Pradeep. >> >> >> >> >> >> > Date: Wed, 16 Sep 2015 08:39:36 +0200 >
Re: FM-Online connect with Manual
BTW, your AJAX-ified FM-Online is already deployed to (http://freemarker-online.kenshoo.com/. -- Thanks, Daniel Dekany Thursday, September 24, 2015, 7:42:28 PM, Daniel Dekany wrote: > Yes. (Note that ICLA is only sufficient if your employer can't claim > that your work belong to them.) > > > Thursday, September 24, 2015, 5:49:25 AM, Pradeep Murugesan wrote: > >> Sure Daniel, >> http://www.apache.org/licenses/icla.pdf >> Will it be sufficient to fill this copy scan and email to >> secret...@apache.org as mentioned here >> http://www.apache.org/licenses/#submitting ? >> Pradeep. >> >>> Date: Wed, 23 Sep 2015 21:45:33 +0200 >>> From: ddek...@freemail.hu >>> To: dev@freemarker.incubator.apache.org >>> Subject: Re: FM-Online connect with Manual >>> >>> OK, that's all fine. >>> >>> If you going to modify Docgen, you will need a CLA at ASF, if you >>> don't yet have it. >>> >>> -- >>> Thanks, >>> Daniel Dekany >>> >>> >>> Wednesday, September 23, 2015, 11:54:20 AM, Pradeep Murugesan wrote: >>> >>> > Hi Daniel, >>> >> Date: Mon, 21 Sep 2015 21:01:25 +0200 >>> >> From: ddek...@freemail.hu >>> >> To: dev@freemarker.incubator.apache.org >>> >> Subject: Re: FM-Online connect with Manual >>> >> >>> >> Sorry... it was in the back of my head, but now... >>> >> >>> >> I see no fundamental problem with it. Some minor notices: >>> >> >>> >> I think it's unnecessary to move the immediate execution functionality >>> >> out to js/execute.js, especially as there's many other "ready" >>> >> functionality just bellow it, inside that "script" element directly. >>> >> It could fit on there. >>> >> >>> > Yeah I moved it over there >>> >> Also I guess it would be more reliable if the immediate execution >>> >> action is the last among the "ready" actions, because that's when it >>> >> happens in the normal (non-Manual) case too. >>> >> >>> > Yeah Non-Manual, we don't this since the button click will trigger the >>> > same. >>> >> Some JavaDoc about FreeMarkerOnlineView constuctor paramteters, >>> >> especially about `execute` wouldn't hurt at this point. >>> >> >>> > I have added the doc. added description only for execute since I >>> > feel other params are explicit. Let me know If i need to add for the >>> > other 2 as well. >>> >> I see your pull request is still pending... Well, after 14 days or so >>> >> I will start asking about it. Also when this current thing is ready, >>> >> push it too. >>> >> >>> >> And yes, you in general you are supposed to work in feature branches >>> >> and push those, otherwise you append to the last "master" push. >>> >> However, I say, this current work can be appended to it, as they >>> >> aren't really separate features. >>> >> >>> > I have added to the same pull request. >>> > Pradeep. >>> >> -- >>> >> Thanks, >>> >> Daniel Dekany >>> >> >>> >> >>> >> Monday, September 21, 2015, 7:43:08 PM, Pradeep Murugesan wrote: >>> >> >>> >> > Daniel, >>> >> > got a chance to review the changes ? >>> >> > Pradeep. >>> >> > >>> >> >> From: pradeepmuruge...@outlook.com >>> >> >> To: dev@freemarker.incubator.apache.org >>> >> >> Subject: RE: FM-Online connect with Manual >>> >> >> Date: Sat, 19 Sep 2015 22:52:11 +0530 >>> >> >> >>> >> >> Hi Daniel, >>> >> >> the POC worked. So I have made the changes to suit our idea of >>> >> >> triggering Ajax when we click from manual. >>> >> >> I have removed the non ajax code and also modified the unit test >>> >> >> cases. Removed a file that is not used after the changes. >>> >> >> https://github.com/pradeepmurugesan/freemarker-online/commit/d90745d91d94503f444fab8ac41d8a0443ac5794 >>> >> >> https://github.com/pradeepmurugesan/freemarker-online/commit/546a73cb4476a8b981858
Re: FM-Online connect with Manual
Yes, I have received it. So now if you send a patch, or, I guess, a
pull request on GitHub
(https://github.com/apache/incubator-freemarker-docgen), then we can
incorporate that. (I have never seen the ASF GitHub integration in
action... let's hope it indeed works. (; )
About the Manual integration. The tricky part is that most examples
assume a data-model, but the data-model is not yet present in parsable
format. So it will have to be added to the DocBook XML somehow, and
only the examples which already has such data-model will be
submittable to FM-Online. My initial idea is this:
x = 1
y = 2
${x} ${y}
So if a template is directly preceded by fmOnlineDataModel, then we
will have a "Try online" button (or whatever it should say). The
fmOnlineDataModel programlisting wouldn't be visible in the output.
On the longer run, we will also need a more serious data model
language. The one we have now is lame when it comes to composite
models. It was dropped together by me quickly, just to have something
instead of the original java.util.Properties format on FM-Online, and
it's owned by Kenshoo. The second iteration should be owned by the
FreeMarker project. It could be integrated into Docgen so that it can
check if the examples indeed run, with the expected output.
That language can also be part of some bolder plans. It can possibly
also be re-used for defining data-model in FTL comments (or in
external file attached, like foo.ftl + foo.ftm), a feature some users
was asking for. This has several uses:
- Helping IDE-s by specifying the expected type of the FTL
variables (see IntelliJ FreeMarker plugin)
- Provide a standard format for documenting the expected data-model
of a template.
- Providing sample values. In simpler applications the template could
even generate output without the backing application using those.
This is the feature FM-Online needs.
Friday, September 25, 2015, 6:06:38 PM, Pradeep Murugesan wrote:
> Done and got an acknowledgement that they have filed it.
> Pradeep.
>
>> Date: Thu, 24 Sep 2015 19:42:28 +0200
>> From: ddek...@freemail.hu
>> To: dev@freemarker.incubator.apache.org
>> Subject: Re: FM-Online connect with Manual
>>
>> Yes. (Note that ICLA is only sufficient if your employer can't claim
>> that your work belong to them.)
>>
>>
>> Thursday, September 24, 2015, 5:49:25 AM, Pradeep Murugesan wrote:
>>
>> > Sure Daniel,
>> > http://www.apache.org/licenses/icla.pdf
>> > Will it be sufficient to fill this copy scan and email to
>> > secret...@apache.org as mentioned here
>> > http://www.apache.org/licenses/#submitting ?
>> > Pradeep.
>> >
>> >> Date: Wed, 23 Sep 2015 21:45:33 +0200
>> >> From: ddek...@freemail.hu
>> >> To: dev@freemarker.incubator.apache.org
>> >> Subject: Re: FM-Online connect with Manual
>> >>
>> >> OK, that's all fine.
>> >>
>> >> If you going to modify Docgen, you will need a CLA at ASF, if you
>> >> don't yet have it.
>> >>
>> >> --
>> >> Thanks,
>> >> Daniel Dekany
>> >>
>> >>
>> >> Wednesday, September 23, 2015, 11:54:20 AM, Pradeep Murugesan wrote:
>> >>
>> >> > Hi Daniel,
>> >> >> Date: Mon, 21 Sep 2015 21:01:25 +0200
>> >> >> From: ddek...@freemail.hu
>> >> >> To: dev@freemarker.incubator.apache.org
>> >> >> Subject: Re: FM-Online connect with Manual
>> >> >>
>> >> >> Sorry... it was in the back of my head, but now...
>> >> >>
>> >> >> I see no fundamental problem with it. Some minor notices:
>> >> >>
>> >> >> I think it's unnecessary to move the immediate execution functionality
>> >> >> out to js/execute.js, especially as there's many other "ready"
>> >> >> functionality just bellow it, inside that "script" element directly.
>> >> >> It could fit on there.
>> >> >>
>> >> > Yeah I moved it over there
>> >> >> Also I guess it would be more reliable if the immediate execution
>> >> >> action is the last among the "ready" actions, because that's when it
>> >> >> happens in the normal (non-Manual) case too.
>> >> >>
>> >> > Yeah Non-Manual, we don't this since the button click will trigger the
>> >> > same.
>> >> >> Some JavaDoc about FreeMarkerOnlineView constuctor paramteters,
Re: improvement on freemarker-online website
Sunday, September 27, 2015, 4:33:19 PM, Daniel Baktiar wrote: > ok, just looked at the freemarker-online, it's been using ajax now. Yeah, seems it's a popular TODO. Pradeep Murugesan has done that recently. > is there anything still need to be done there? Sure, though it will have to be coordinated with Pradeep too, so your work doesn't clash: - Indentation handling (like in real code editors) and perhaps syntax highlighting. But I see Evangelia has just wrote about that. - Integration with the FreeMarker Manual - Better data description language. This last two is discussed here further: http://mail-archives.apache.org/mod_mbox/incubator-freemarker-dev/201509.mbox/browser Also if you see something where you thing it should be improved, or would be just fun/interesting to improve for you, tell us. > On Sun, Sep 27, 2015 at 10:30 PM, Daniel Baktiar wrote: > >> hi, >> >> I saw here >> http://freemarker.org/contribute.html >> >> that contributors wanted for the freemarker-online, to make it more >> attractive by using some ajax rather than reloading page. >> i think i could do something on that front. >> >> whom should i contact for this? >> >> regards, >> daniel -- Thanks, Daniel Dekany
Someone wants to help with the JBoss IDE plugin?
So it's on http://freemarker.org/contribute.html, but... - I just want to emphasize that it's quite important for the success of the project. People need to edit the templates with something, and efficiently. For you convenience, the pending Jira issues: https://issues.jboss.org/browse/JBIDE-20512?jql=project%20%3D%20JBIDE%20AND%20status%20in%20%28Open%2C%20%22Coding%20In%20Progress%22%2C%20Reopened%2C%20%22Pull%20Request%20Sent%22%29%20AND%20component%20%3D%20freemarker - You can help even if you aren't into Eclipse plugin development! A problem is currently that the release of the plugin seems to be bound to the release of the JBoss Tools project which is very infrequent for our purpose. Maybe the fixes should just be back-ported into the previous JBoss Tools branch too solve that, and that's not done, but I really don't know. In any case, currently, FreeMarker IDE release cycles are way too slow [*]. A solution for this should be figured out, and discussed with the JBoss Tools guys. Like, just as an example, maybe we should set up our own plugin update site, and do the builds ourselves, but then legal issues has to be considered, and if that could interfere with the JBoss Tools installation of the users. *: For example, I have asked to increase the FreeMarker version in 2.3.23. And sure it was done in the repo quickly (thanks to Denis Golovin who has also squashed several FreeMarker IDE bugs), but it's scheduled for JBoss Tools 4.4.0. That, I guess, is about 12 months away! Until that, FreeMarker IDE won't handle the new features of 2.3.23, which was released months ago. Or, FreeMarker IDE was pretty much unusably broken in 4.2.0. Months ago, it was fixed, and now its quite usable. Big difference. But for most user that will only become visible in 4.3.0, which is has only entered CR1 state not very long ago. Now, it all could be kind of OK, if there were JBoss IDE dependencies in FreeMarker IDE, or the other way around, but as far as I see there's pretty much none. So technically FreeMarker IDE could be released independently. -- Thanks, Daniel Dekany
Re: FM-Online connect with Manual
Monday, September 28, 2015, 8:34:48 PM, Pradeep Murugesan wrote:
> Hi Daniel,
> Sure, Got a busy weekend. So couldn't look into you email. Sorry for the
> delayed response.
> I will start working on connecting the manual with FM online .
> Regarding the datamodel language we can come to it after we
> integrate what we have already right ?
Right.
--
Thanks,
Daniel Dekany
> Pradeep.
>> Date: Sat, 26 Sep 2015 10:11:28 +0200
>> From: ddek...@freemail.hu
>> To: dev@freemarker.incubator.apache.org
>> Subject: Re: FM-Online connect with Manual
>>
>> Yes, I have received it. So now if you send a patch, or, I guess, a
>> pull request on GitHub
>> (https://github.com/apache/incubator-freemarker-docgen), then we can
>> incorporate that. (I have never seen the ASF GitHub integration in
>> action... let's hope it indeed works. (; )
>>
>> About the Manual integration. The tricky part is that most examples
>> assume a data-model, but the data-model is not yet present in parsable
>> format. So it will have to be added to the DocBook XML somehow, and
>> only the examples which already has such data-model will be
>> submittable to FM-Online. My initial idea is this:
>>
>>
>> x = 1
>> y = 2
>>
>>
>> ${x} ${y}
>>
>>
>> So if a template is directly preceded by fmOnlineDataModel, then we
>> will have a "Try online" button (or whatever it should say). The
>> fmOnlineDataModel programlisting wouldn't be visible in the output.
>>
>> On the longer run, we will also need a more serious data model
>> language. The one we have now is lame when it comes to composite
>> models. It was dropped together by me quickly, just to have something
>> instead of the original java.util.Properties format on FM-Online, and
>> it's owned by Kenshoo. The second iteration should be owned by the
>> FreeMarker project. It could be integrated into Docgen so that it can
>> check if the examples indeed run, with the expected output.
>>
>> That language can also be part of some bolder plans. It can possibly
>> also be re-used for defining data-model in FTL comments (or in
>> external file attached, like foo.ftl + foo.ftm), a feature some users
>> was asking for. This has several uses:
>> - Helping IDE-s by specifying the expected type of the FTL
>> variables (see IntelliJ FreeMarker plugin)
>> - Provide a standard format for documenting the expected data-model
>> of a template.
>> - Providing sample values. In simpler applications the template could
>> even generate output without the backing application using those.
>> This is the feature FM-Online needs.
>>
>>
>> Friday, September 25, 2015, 6:06:38 PM, Pradeep Murugesan wrote:
>>
>> > Done and got an acknowledgement that they have filed it.
>> > Pradeep.
>> >
>> >> Date: Thu, 24 Sep 2015 19:42:28 +0200
>> >> From: ddek...@freemail.hu
>> >> To: dev@freemarker.incubator.apache.org
>> >> Subject: Re: FM-Online connect with Manual
>> >>
>> >> Yes. (Note that ICLA is only sufficient if your employer can't claim
>> >> that your work belong to them.)
>> >>
>> >>
>> >> Thursday, September 24, 2015, 5:49:25 AM, Pradeep Murugesan wrote:
>> >>
>> >> > Sure Daniel,
>> >> > http://www.apache.org/licenses/icla.pdf
>> >> > Will it be sufficient to fill this copy scan and email to
>> >> > secret...@apache.org as mentioned here
>> >> > http://www.apache.org/licenses/#submitting ?
>> >> > Pradeep.
>> >> >
>> >> >> Date: Wed, 23 Sep 2015 21:45:33 +0200
>> >> >> From: ddek...@freemail.hu
>> >> >> To: dev@freemarker.incubator.apache.org
>> >> >> Subject: Re: FM-Online connect with Manual
>> >> >>
>> >> >> OK, that's all fine.
>> >> >>
>> >> >> If you going to modify Docgen, you will need a CLA at ASF, if you
>> >> >> don't yet have it.
>> >> >>
>> >> >> --
>> >> >> Thanks,
>> >> >> Daniel Dekany
>> >> >>
>> >> >>
>> >> >> Wednesday, September 23, 2015, 11:54:20 AM, Pradeep Murugesan wrote:
>> >> >>
>> >> >> > Hi Daniel,
>> >> >> >> Date: Mon, 21 Sep 2015 21:01:25 +0200
>> >> >
Re: Option names in extended DecimalFormat format strings
What about the other names? (BTW, "curc" stand for "currencyCode"...
mostly because we also have "currencySymbol".)
And, anyone else has opinion?
Thursday, September 24, 2015, 2:14:29 AM, Evangelia Dendramis wrote:
> I've found it's always easier if the values are spelled out. I would prefer
> specifying "currency" to "curc" even though the line of code will be longer.
>
> On Wed, Sep 23, 2015 at 4:12 PM, Daniel Dekany wrote:
>
>> Earlier I have talked (and held a vote) about extended format strings,
>> but as reminder, for a while in 2.3.24 nightly you can do things like
>> this:
>>
>> ${n?string("#.00;; rnd=hu inf='∞'")}
>>
>> or set the number_format setting to something like that. The thing to
>> note is the section after the 2nd ";", which is not allowed be
>> DecimalFormat (as it only supports two sections), it's an extension by
>> FreeMarker.
>>
>> How should the option names look? Like instead of the current
>> abbreviated form, it could be like "#.00;; rounding='half-up'
>> infinity='∞'" too. Currently it's like below. Opinions?
>>
>>
>> rnd
>> Rounding mode. The value is one of u for up, d for down, c for
>> ceiling, f for floor, hu for half-up, hd for half-down, he for
>> half-even, and un for unused. (See the java.math.RoundingMode API
>> for explanations.)
>>
>> mul
>> Multiplier. The number will be shown after multiplied with this
>> integer number.
>>
>> dec
>> Decimal separator character (like "." in 3.14).
>>
>> mdec
>> Monetary decimal separator character. This is used instead of dec
>> when the pattern contains parts that make it a monetary format. (See
>> the Java decimal number format documentation for more.)
>>
>> grp
>> Grouping separator character. Note that grouping is turned on by
>> using "," in the patter, as shown in the earlier example. If it's
>> not turned on, this option won't have visible effect.
>>
>> exp
>> Exponent separator string. Only has visible effect if the pattern
>> specifies exponential form, like "0.##E0".
>>
>> min
>> Minus sign character.
>>
>> inf
>> The string used to show infinity.
>>
>> nan
>> The string used to show not-a-number (NaN).
>>
>> prc
>> Percent character.
>>
>> prm
>> Per-mill character.
>>
>> zero
>> Zero character. This modifies the other digits too, for example, if
>> zero is A, then 1 will B, 2 will be C, and so on.
>>
>> curc
>> Currency ISO 4217 code. Only has effect when the pattern contains
>> parts that make it a monetary format. It's an error to specify a
>> code that's not a known ISO 4217 code in the Java installation.
>>
>> curs
>> Currency symbol; shown where the localized currency name is present
>> in the pattern. Overrides the symbol determined from curc.
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>>
--
Thanks,
Daniel Dekany
Re: Freemarker manual Local set up
FM is *built* with JDK 8 (and runs on Java 5+ as of 2.3.24). This information was missing from the README.txt... I have fixed that now. The important thing is to ensure that Ant runs on JDK 8 too. Perhaps you need to adjust the JAVA_HOME environment variable for that. (Clearing the Ivy or Ant directories is not needed.) Tuesday, September 29, 2015, 8:56:44 PM, Pradeep Murugesan wrote: > Tried upgrading to java 1.8 and cleared the ant and ivy cache. > still facing the same issue. Have any of you guys faced this already > Pradeep. > >> From: pradeepmuruge...@outlook.com >> To: dev@freemarker.incubator.apache.org >> Subject: RE: Freemarker manual Local set up >> Date: Tue, 29 Sep 2015 08:43:05 +0530 >> >> Hi, I tried to do "ant manualFreemarkerOrg" to bring up the manual locally. >> But end up in the following error. >> BUILD >> FAILEDC:\Users\pmuruge\Desktop\Pradeep\Personal\github\apache\freemarker\incubator-freemarker\build.xml:570: >> The following error occurred while executing this >> line:C:\Users\pmuruge\Desktop\Pradeep\Personal\github\apache\freemarker\incubator-freemarker\build.xml:556: >> java.lang.UnsupportedClassVersionError: >> org/freemarker/docgen/TransformAntTask : Unsupported major.minor version 52.0 >> >> Googling got me to the state that the docgen jar would have been build using >> different java and from the github readme understood that docgen requires >> java 1.8. which means compiling Freemarker project also require Java 1.8 ? >> Its not mentioned in Freemarker readme though. >> Please guide me. >> Also, >> How are you guys working with multiple java versions in the same machine. >> BTW I am using Windows and tried to manage java 1.7 & java 1.8 but failed >> with an error . If you guys are already following some way kindly let me >> know. >> >> Pradeep. >> >> >> > Date: Wed, 23 Sep 2015 20:34:03 +0200 >> > From: ddek...@freemail.hu >> > To: dev@freemarker.incubator.apache.org >> > Subject: Re: Freemarker manual Local set up >> > >> > The Manual is in the "freemarker" project, under src/manual. It also >> > uses docgen of course. (You can download the latest docgen artifact >> > with running `ant update-deps` in the "freemarker" project.) The >> > manual is built with `ant manualOffline` or `manualFreemarkerOrg`. >> > >> > As of README-s, all 3 modules (freemarker, site, docgen) has one, so >> > what's not described there is probably undocumented... >> > >> > Anyway, it's docgen's responsibility to generate the hidden HTML forms >> > and JavaScript that will be needed. (Both the Web site and the Manual >> > is built from DocBook XML by Docgen.) >> > >> > -- >> > Thanks, >> > Daniel Dekany >> > >> > >> > Wednesday, September 23, 2015, 7:33:05 PM, Pradeep Murugesan wrote: >> > >> > > Hi Daniel, >> > >I could see that freemarker manual is part of the site >> > > http://freemarker.org/docs/index.html >> > > Since that is generated using the doc-gen, I am trying to look into >> > > the https://github.com/apache/incubator-freemarker-site for manual >> > > contents. >> > > https://github.com/apache/incubator-freemarker-site/blob/master/src/main/docgen/book.xml >> > > references to the site but I am not able to get the xml for manual which >> > > doc-gen converts. >> > > >> > > I am trying to get the manual up and running locally to connect >> > > with the freemarker online. Is there any readme kind of thing to achieve >> > > the same ? >> > > Please guide me. >> > > Pradeep. >> > >> > -- Thanks, Daniel Dekany
Re: Option names in extended DecimalFormat format strings
The terminology comes from Java's DecimalFormatSymbols, so if we write
it out as "minus" anyway, I would stick to it.
--
Thanks,
Daniel Dekany
Tuesday, September 29, 2015, 8:34:30 PM, Pradeep Murugesan wrote:
> I feel min sounds like it denotes minimum than minus.
> can we use Subtract as synonym and have sub as option name ? just a thought.
> Pradeep.
>
>> Date: Tue, 29 Sep 2015 10:26:31 -0700
>> Subject: Re: Option names in extended DecimalFormat format strings
>> From: evangel...@gmail.com
>> To: dev@freemarker.incubator.apache.org; ddek...@freemail.hu
>>
>> I would spell everything out
>>
>> rnd -> roundingMode
>> mul -> multiplier
>> dec -> decimalSeparator
>> mdec -> monetaryDecimalSeparator
>> grp -> groupingSeparator
>> exp -> exponentSeparator
>> min -> minus
>> inf -> infinity
>> nan -> nan
>> prm -> perMillion
>> zero -> zeroChar
>> curc -> currencyCode
>> curs -> currencySymbol
>>
>> On Mon, Sep 28, 2015 at 5:28 PM, Daniel Dekany wrote:
>>
>> > What about the other names? (BTW, "curc" stand for "currencyCode"...
>> > mostly because we also have "currencySymbol".)
>> >
>> > And, anyone else has opinion?
>> >
>> >
>> > Thursday, September 24, 2015, 2:14:29 AM, Evangelia Dendramis wrote:
>> >
>> > > I've found it's always easier if the values are spelled out. I would
>> > prefer
>> > > specifying "currency" to "curc" even though the line of code will be
>> > longer.
>> > >
>> > > On Wed, Sep 23, 2015 at 4:12 PM, Daniel Dekany
>> > wrote:
>> > >
>> > >> Earlier I have talked (and held a vote) about extended format strings,
>> > >> but as reminder, for a while in 2.3.24 nightly you can do things like
>> > >> this:
>> > >>
>> > >> ${n?string("#.00;; rnd=hu inf='∞'")}
>> > >>
>> > >> or set the number_format setting to something like that. The thing to
>> > >> note is the section after the 2nd ";", which is not allowed be
>> > >> DecimalFormat (as it only supports two sections), it's an extension by
>> > >> FreeMarker.
>> > >>
>> > >> How should the option names look? Like instead of the current
>> > >> abbreviated form, it could be like "#.00;; rounding='half-up'
>> > >> infinity='∞'" too. Currently it's like below. Opinions?
>> > >>
>> > >>
>> > >> rnd
>> > >> Rounding mode. The value is one of u for up, d for down, c for
>> > >> ceiling, f for floor, hu for half-up, hd for half-down, he for
>> > >> half-even, and un for unused. (See the java.math.RoundingMode API
>> > >> for explanations.)
>> > >>
>> > >> mul
>> > >> Multiplier. The number will be shown after multiplied with this
>> > >> integer number.
>> > >>
>> > >> dec
>> > >> Decimal separator character (like "." in 3.14).
>> > >>
>> > >> mdec
>> > >> Monetary decimal separator character. This is used instead of dec
>> > >> when the pattern contains parts that make it a monetary format. (See
>> > >> the Java decimal number format documentation for more.)
>> > >>
>> > >> grp
>> > >> Grouping separator character. Note that grouping is turned on by
>> > >> using "," in the patter, as shown in the earlier example. If it's
>> > >> not turned on, this option won't have visible effect.
>> > >>
>> > >> exp
>> > >> Exponent separator string. Only has visible effect if the pattern
>> > >> specifies exponential form, like "0.##E0".
>> > >>
>> > >> min
>> > >> Minus sign character.
>> > >>
>> > >> inf
>> > >> The string used to show infinity.
>> > >>
>> > >> nan
>> > >> The string used to show not-a-number (NaN).
>> > >>
>> > >> prc
>> > >> Percent character.
>> > >>
>> > >> prm
>> > >> Per-mill character.
>> > >>
>> > >> zero
>> > >> Zero character. This modifies the other digits too, for example, if
>> > >> zero is A, then 1 will B, 2 will be C, and so on.
>> > >>
>> > >> curc
>> > >> Currency ISO 4217 code. Only has effect when the pattern contains
>> > >> parts that make it a monetary format. It's an error to specify a
>> > >> code that's not a known ISO 4217 code in the Java installation.
>> > >>
>> > >> curs
>> > >> Currency symbol; shown where the localized currency name is present
>> > >> in the pattern. Overrides the symbol determined from curc.
>> > >>
>> > >> --
>> > >> Thanks,
>> > >> Daniel Dekany
>> > >>
>> > >>
>> >
>> > --
>> > Thanks,
>> > Daniel Dekany
>> >
>> >
>
Re: freemarker plugin
Tuesday, September 29, 2015, 9:48:57 AM, Max Rydahl Andersen wrote: > Hi Daniel, > > I saw your post on > http://mail-archives.apache.org/mod_mbox/incubator-freemarker-dev/201509.mbox/browser > and a few pinged me on it. > > I just wanted to clarify a few things (I can't post/respond on the > mailing list since I no longer subscribe to it): (You can actually, it just will be moderated in manually.) > * The original codebase for freemarker IDE was dead ~8 years ago and I > picked it up and >maintained it as part of JBoss Tools release so it could get regular > releases. > > * 4.2.x was not a good release for freemarker tools, this was where we > accepted external patches without having time to test and maintain it. > I'm sorry for that :/ > > * It is included into Hibernate Tools since we use freemarker as > template language. (this is not a limitation, just stating we do depend > on it) > > * We have builds of it every night - so fixes are available as soon as > they can be. > > * Our regular public release cadence is about every 1-2 months, For JBoss Tools? (Said FM version update was scheduled for something like 4.4.0, 2016 September on Jira.) > but anyone want something more fresh can use the nightly. Should we advise average users to install from the nightly repo instead of from Eclipse Marketplace? I mean, do they only risk getting an unstable FreeMarker IDE? (BTW, I have tried using JBoss Tools nightly builds Eclipse update site few months ago. Surely it's much faster than waiting for stable releases, but for some reason FreeMarker IDE wasn't updated as often as it was committed into. I have ended up checking it out from GitHub and build it locally.) > * We merge in any PR's we can find time to do. (as I hope you can > verify) > > * We do not support multiple patch streams for multiples versions of > Eclipse since we just don't have the time/resources to do so. But afaik > latest mars Freemarker can be installed on even older versions. Just not > verified. > > That said, I very much know we could do more fixes/changes, but I have > always said: If anyone shows up and are willing to do the testing and > the builds we can arrange for this individual component to do more > builds on its own. > > Just need someone to do that work. Yes, of course, that's why I have asked help on the FreeMarker dev list. (I didn't mean to blame JBoss Tools developers or something like that.) I myself try to focus on FreeMarker core development. That goes slowly enough because of lack of resources, so I try to dish out other tasks to others. (Not mention, that if I do everything, that's won't be acceptable for ASF either.) > Just like I/we took it on many years ago, someone else can continue > that. > > Only wish I have is that the main features don't break installation API > and listens/help do fixes when JBoss Tools is about to release. > > So if you or someone else want to jump in and do more releases of > freemarker in addition to the one we already do - let me know and we'll > figure it out! Thanks for the detailed answer! > /max > http://about.me/maxandersen -- Thanks, Daniel Dekany
Re: Option names in extended DecimalFormat format strings
OK, I have renamed these (to the names used in
java.text.DecimalFormatSymbols, so it's "perMill".)
--
Thanks,
Daniel Dekany
Tuesday, September 29, 2015, 7:26:31 PM, Evangelia Dendramis wrote:
> I would spell everything out
>
rnd ->> roundingMode
mul ->> multiplier
dec ->> decimalSeparator
mdec ->> monetaryDecimalSeparator
grp ->> groupingSeparator
exp ->> exponentSeparator
min ->> minus
inf ->> infinity
nan ->> nan
prm ->> perMillion
zero ->> zeroChar
curc ->> currencyCode
curs ->> currencySymbol
>
> On Mon, Sep 28, 2015 at 5:28 PM, Daniel Dekany wrote:
> What about the other names? (BTW, "curc" stand for "currencyCode"...
> mostly because we also have "currencySymbol".)
>
> And, anyone else has opinion?
>
>
> Thursday, September 24, 2015, 2:14:29 AM, Evangelia Dendramis wrote:
>
>> I've found it's always easier if the values are spelled out. I would prefer
>> specifying "currency" to "curc" even though the line of code will be longer.
>>
>> On Wed, Sep 23, 2015 at 4:12 PM, Daniel Dekany wrote:
>>
>>> Earlier I have talked (and held a vote) about extended format strings,
>>> but as reminder, for a while in 2.3.24 nightly you can do things like
>>> this:
>>>
>>> ${n?string("#.00;; rnd=hu inf='∞'")}
>>>
>>> or set the number_format setting to something like that. The thing to
>>> note is the section after the 2nd ";", which is not allowed be
>>> DecimalFormat (as it only supports two sections), it's an extension by
>>> FreeMarker.
>>>
>>> How should the option names look? Like instead of the current
>>> abbreviated form, it could be like "#.00;; rounding='half-up'
>>> infinity='∞'" too. Currently it's like below. Opinions?
>>>
>>>
>>> rnd
>>> Rounding mode. The value is one of u for up, d for down, c for
>>> ceiling, f for floor, hu for half-up, hd for half-down, he for
>>> half-even, and un for unused. (See the java.math.RoundingMode API
>>> for explanations.)
>>>
>>> mul
>>> Multiplier. The number will be shown after multiplied with this
>>> integer number.
>>>
>>> dec
>>> Decimal separator character (like "." in 3.14).
>>>
>>> mdec
>>> Monetary decimal separator character. This is used instead of dec
>>> when the pattern contains parts that make it a monetary format. (See
>>> the Java decimal number format documentation for more.)
>>>
>>> grp
>>> Grouping separator character. Note that grouping is turned on by
>>> using "," in the patter, as shown in the earlier example. If it's
>>> not turned on, this option won't have visible effect.
>>>
>>> exp
>>> Exponent separator string. Only has visible effect if the pattern
>>> specifies exponential form, like "0.##E0".
>>>
>>> min
>>> Minus sign character.
>>>
>>> inf
>>> The string used to show infinity.
>>>
>>> nan
>>> The string used to show not-a-number (NaN).
>>>
>>> prc
>>> Percent character.
>>>
>>> prm
>>> Per-mill character.
>>>
>>> zero
>>> Zero character. This modifies the other digits too, for example, if
>>> zero is A, then 1 will B, 2 will be C, and so on.
>>>
>>> curc
>>> Currency ISO 4217 code. Only has effect when the pattern contains
>>> parts that make it a monetary format. It's an error to specify a
>>> code that's not a known ISO 4217 code in the Java installation.
>>>
>>> curs
>>> Currency symbol; shown where the localized currency name is present
>>> in the pattern. Overrides the symbol determined from curc.
>>>
>>> --
>>> Thanks,
>>> Daniel Dekany
>>>
>>>
>
> --
> Thanks,
> Daniel Dekany
>
>
PPMC members, please read and sign the October report
https://wiki.apache.org/incubator/October2015 -- Thanks, Daniel Dekany
Re: Mailing list subscription
Wednesday, October 7, 2015, 10:45:19 AM, jean-frederic clere wrote: > On 10/06/2015 03:52 PM, vishnu vardhan wrote: >> HI, >> I want to start contributing to Freemaker.please help me in staring the >> contribution. >> > > Usually the first steps are to install the project (and build it) to get > familiar with it. Also note that we have these: http://freemarker.org/contribute.html http://freemarker.org/sourcecode.html (Later I will extend and cross-link these, etc.) > BTW: I have noted there isn't any JIRA created, we should create some. We do have Jira (see also the October report): https://issues.apache.org/jira/browse/FREEMARKER Though, earlier issues weren't yet migrated: https://sourceforge.net/p/freemarker/bugs/ > Cheers > > Jean-Frederic > -- Thanks, Daniel Dekany
2.3.24-RC1 delay...
Seems 2.3.24-RC1 is delaying further and further... Some stuff turned
out to be more problematic as I thought (for example ${...}-s inside
string literal VS formatting to markup), and then September came and I
suddenly become rather overburden. Not sure when will I find the time
to finish RC1. Can even be weeks, as things look...
--
Thanks,
Daniel Dekany
Re: incubator-freemarker-site git commit: More getting started info for new contributors.
Indeed, it has a read-only mirror at https://github.com/apache/incubator-freemarker/tree/2.3-gae. I will add that to out web site. You can fork that and send pull requests using the usual GitHub functions (I hope... haven't seen it in action yet). Regarding bug fixing. Older bugs are usually there because there's something tricky with them. But here's a newer one, which should be reproduced to star with: https://sourceforge.net/p/freemarker/bugs/434/. Or because the report wasn't understood (https://sourceforge.net/p/freemarker/bugs/369/). But pick whichever you like, of course. Please use the developer mailing list, not my address! -- Thanks, Daniel Dekany Saturday, October 10, 2015, 2:33:41 PM, Garvit Bansal wrote: > Thanks a lot. > Freemarker Source code can be downloaded from git hub right ? > I see some of open bugs on sourceforget.net. Will be grateful easy bug to > start with. > > Garvit Bansal, > Software Developer Intern at Flipkart > B.Tech in Computer Science and Engineering > The LNM Institute of Information Technology > Jaipur, Rajasthan-302001 > Mobile: 9610728532, 9886384276 > Website: garvitbansal244.appspot.com > > > > > On Sat, Oct 10, 2015 at 4:03 AM, Daniel Dekany wrote: > Friday, October 9, 2015, 7:51:53 PM, Garvit Bansal wrote: > >> Link not working: >> https://git1-us-west.apache.org/repos/asf/incubator-freemarker-site/repo > > Where did you find that link? Anyway, the correct addresses are here: > http://freemarker.org/sourcecode.html > >> I gone through Readme file and did as per given in Readme still build is >> failing. >> >> Garvit Bansal, >> Software Developer Intern at Flipkart >> B.Tech in Computer Science and Engineering >> The LNM Institute of Information Technology >> Jaipur, Rajasthan-302001 >> Mobile: 9610728532, 9886384276 >> Website: garvitbansal244.appspot.com >> >> >> >> >> On Fri, Oct 9, 2015 at 11:03 PM, Daniel Dekany wrote: >> Friday, October 9, 2015, 7:23:07 PM, Garvit Bansal wrote: >> >>> Hey Daniel, >>> >>> I am new in this project. I tried to open the project link given in your >>> mail but its not working. >> >> Which link? >> >>> Earlier I cloned the project from github repository of >>> incubator-freemarker and tried to build it but facing some issues. >> >> Be sure you have read the README.txt! >> >>> Cheers, >>> Garvit >>> >>> Garvit Bansal, >>> Software Developer Intern at Flipkart >>> B.Tech in Computer Science and Engineering >>> The LNM Institute of Information Technology >>> Jaipur, Rajasthan-302001 >>> Mobile: 9610728532, 9886384276 >>> Website: garvitbansal244.appspot.com >>> >>> >>> >>> >>> On Fri, Oct 9, 2015 at 10:39 PM, wrote: >>> Repository: incubator-freemarker-site >>> Updated Branches: >>> refs/heads/master 699630fe6 -> 149fc6ad2 >>> >>> >>> More getting started info for new contributors. >>> >>> >>> Project: >>> http://git-wip-us.apache.org/repos/asf/incubator-freemarker-site/repo >>> Commit: >>> http://git-wip-us.apache.org/repos/asf/incubator-freemarker-site/commit/149fc6ad >>> Tree: >>> http://git-wip-us.apache.org/repos/asf/incubator-freemarker-site/tree/149fc6ad >>> Diff: >>> http://git-wip-us.apache.org/repos/asf/incubator-freemarker-site/diff/149fc6ad >>> >>> Branch: refs/heads/master >>> Commit: 149fc6ad27b9cd475be5fa9d1d79fd8a7982c7e8 >>> Parents: 699630f >>> Author: ddekany >>> Authored: Fri Oct 9 19:09:36 2015 +0200 >>> Committer: ddekany >>> Committed: Fri Oct 9 19:09:36 2015 +0200 >>> >>> -- >>> src/main/docgen/book.xml | 6 ++ >>> 1 file changed, 6 insertions(+) >>> -- >>> >>> >>> http://git-wip-us.apache.org/repos/asf/incubator-freemarker-site/blob/149fc6ad/src/main/docgen/book.xml >>> -- >>> diff --git a/src/main/docgen/book.xml b/src/main/docgen/book.xml >>> index 276e3fa..8b22688 100644 >>> --- a/src/main/docgen/book.xml >>> +++ b/src/main/docgen/book.xml >>> @@ -1156,6 +1156,12 @@ two freemarker.jar-s and unpredictable behavior! >>> >>> xlink:href="http://www.apache.org/dev/new-committers-guide.html#cla";>Individual >>> Contributor License Agreement (ICLA) or Corporate CLA at the Apache >>> Software Foundation. >>> + >>> +Of course, you will also want to check the project out from >>> the >>> +source code repository, and build it. See here >> +linkend="sourcecode">what to check out. After checking >>> +something out, see the README file in it for >>> more >>> +information about building and IDE setup. >>> >>> >>> >>> >>> >> >> -- >> Thanks, >> Daniel Dekany >> > > -- > Thanks, > Daniel Dekany >
Re: Question on unit testing
Sunday, October 11, 2015, 4:56:34 AM, Woonsan Ko wrote: > Hi, > > When I added a new unit test, `ant test' seems failing in many test > classes. e.g, FileTemplateLoaderTest, etc. Maybe you ran into bugs in the test suite itself then. They are supposed to pass without doing anything special. I have only ever ran the test suite on Windows, and that's perhaps where the difference lies. They also must be all green if you ran them from Eclipse (or IntelliJ, etc.), and that's how I do it most of the time, since it's easier to navigate to errors, etc. You don't need the command line except for running JavaCC once (or after you have changed FTL.jj), and perhaps before a pull request to see if you have accidentally used a non-Java 5 API. Anyway, can you look at the concrete errors to see if they are environment dependencies? > So, I had to change build.xml (in batchtest task) to include only my > new test class locally. At least in Eclipse I can just right click on a package or class or method, and run it as JUnit test. (Then F11 to re-run it.) > My dev env is Ant 1.9.6 (Ivy 2.4.0) and JDK 1.8 on OSX. JDK 1.8 64 bit, 1.8.1, Windows 7 here... but if this matters, then that should be fixed. > How can I run all the unit tests successfully? > Also, is there any tip to run single unit test in command line (like > `mvn test -Dtest=...')? I think there was, but I don't remember the exact syntax anymore. But using you IDE is more efficient anyway. > Thanks in advance, > > Woonsan > -- Thanks, Daniel Dekany
Re: Question on unit testing
Sunday, October 11, 2015, 1:57:53 PM, Woonsan Ko wrote: [snip] > junit.framework.AssertionFailedError > at > freemarker.cache.FileTemplateLoaderTest.testCaseSensitivity(FileTemplateLoaderTest.java:101) > > I'm not sure if OSX behaves like Windows somehow when resolving a file It's case sensitive AFAIK, while Windows isn't. > or if this is something else yet. > I also tried it after excluding FileTemplateLoaderTest, but there are > other tests failing.. > Anyway, I stopped there for now because this is not related to my pull > request. ;-) I'll look into the unit test issues later. > >> >>> So, I had to change build.xml (in batchtest task) to include only my >>> new test class locally. >> >> At least in Eclipse I can just right click on a package or class or >> method, and run it as JUnit test. (Then F11 to re-run it.) >> >>> My dev env is Ant 1.9.6 (Ivy 2.4.0) and JDK 1.8 on OSX. >> >> JDK 1.8 64 bit, 1.8.1, Windows 7 here... but if this matters, then >> that should be fixed. >> >>> How can I run all the unit tests successfully? >>> Also, is there any tip to run single unit test in command line (like >>> `mvn test -Dtest=...')? >> >> I think there was, but I don't remember the exact syntax anymore. But >> using you IDE is more efficient anyway. > > I'm used to Maven and Maven plugins for Eclipse, where I was able to > run unit test in IDE easily. Ant/Ivy/Eclipse environment looks a bit > different to me. I need some more time to learn. No plugin is needed. Just right click, and Run as JUnit test. > By the way, IIRC, you mentioned in old ML that it's planned to migrate > to Maven some day. Is it right? If so, when do you want to do that? I'm not sure if that would work out well, given that FM needs to be compiled against multiple versions of the same library (including rt.jar). But if someone works this topic out, it might turns out that it's feasible after all. I don't know. But the bet is on Gradle. And that will probably only happen when someone other than me takes that task. > Kind regards, > > Woonsan > >> >>> Thanks in advance, >>> >>> Woonsan >>> >> >> -- >> Thanks, >> Daniel Dekany >> > -- Thanks, Daniel Dekany
Re: Freemarker manual Local set up
I'm not sure where exactly you stuck, but I try to give some pointers. Read http://freemarker.org/docs/xgui.html if you haven't. As you will see there, you got the current XML node as .node in the programlisting macro, and you can move around in the DOM tree from there, like examine the previous/next programlisting, etc. As of shrinking the content, certainly you should work with a minimalistic docbook. I don't know what error you get. (Of course the XML must be well-formed XDocBook.) -- Thanks, Daniel Dekany Sunday, October 11, 2015, 5:50:06 PM, Pradeep Murugesan wrote: > Hi Daniel, > I am still trying to knock it down but in vain. I dig down to > programListing macro in NodeHandlers.ftlh and I am lost there as what is > going on. > I tried to shrink the content in book.xml and ran docgen to > understand where do i need to inject the logic but that approach threw few > other errors. > > It comes all the way down to generateHTMLFile_inner where we get > page.fthl and process it and I am not able to proceed further. > Could you please give me a clue ? > Pradeep. >> From: pradeepmuruge...@outlook.com >> To: dev@freemarker.incubator.apache.org >> Subject: RE: Freemarker manual Local set up >> Date: Mon, 5 Oct 2015 14:45:09 +0530 >> >> Hi Daniel, >> >> I am going through the docgen code and its taking some time to clearly get >> what is happening in the Transform.java. >> I am tracing down to the part where to check if the previous node is >> frmDataModel if the current node is Template so that I have a hidden form >> and try it out button. I am facing some challenges there. >> I will try to complete things within this week. >> Pradeep. >> >> > Date: Tue, 29 Sep 2015 21:45:41 +0200 >> > From: ddek...@freemail.hu >> > To: pradeepmuruge...@outlook.com >> > CC: dev@freemarker.incubator.apache.org >> > Subject: Re: Freemarker manual Local set up >> > >> > FM is *built* with JDK 8 (and runs on Java 5+ as of 2.3.24). This >> > information was missing from the README.txt... I have fixed that now. >> > The important thing is to ensure that Ant runs on JDK 8 too. Perhaps >> > you need to adjust the JAVA_HOME environment variable for that. >> > (Clearing the Ivy or Ant directories is not needed.) >> > >> > >> > Tuesday, September 29, 2015, 8:56:44 PM, Pradeep Murugesan wrote: >> > >> > > Tried upgrading to java 1.8 and cleared the ant and ivy cache. >> > > still facing the same issue. Have any of you guys faced this already >> > > Pradeep. >> > > >> > >> From: pradeepmuruge...@outlook.com >> > >> To: dev@freemarker.incubator.apache.org >> > >> Subject: RE: Freemarker manual Local set up >> > >> Date: Tue, 29 Sep 2015 08:43:05 +0530 >> > >> >> > >> Hi, I tried to do "ant manualFreemarkerOrg" to bring up the manual >> > >> locally. >> > >> But end up in the following error. >> > >> BUILD >> > >> FAILEDC:\Users\pmuruge\Desktop\Pradeep\Personal\github\apache\freemarker\incubator-freemarker\build.xml:570: >> > >> The following error occurred while executing this >> > >> line:C:\Users\pmuruge\Desktop\Pradeep\Personal\github\apache\freemarker\incubator-freemarker\build.xml:556: >> > >> java.lang.UnsupportedClassVersionError: >> > >> org/freemarker/docgen/TransformAntTask : Unsupported major.minor >> > >> version 52.0 >> > >> >> > >> Googling got me to the state that the docgen jar would have been build >> > >> using different java and from the github readme understood that docgen >> > >> requires java 1.8. which means compiling Freemarker project also >> > >> require Java 1.8 ? Its not mentioned in Freemarker readme though. >> > >> Please guide me. >> > >> Also, >> > >> How are you guys working with multiple java versions in the same >> > >> machine. BTW I am using Windows and tried to manage java 1.7 & java 1.8 >> > >> but failed with an error . If you guys are already following some way >> > >> kindly let me know. >> > >> >> > >> Pradeep. >> > >> >> > >> >> > >> > Date: Wed, 23 Sep 2015 20:34:03 +0200 >> > >> > From: ddek...@freemail.hu >> > >> > To: dev@freemarker.incubator.apache.org >> > >> > Subject: Re: Freemarker manual Local se
Re: Question on unit testing
Just wanted to say that I will eventually get to this and the other
pull request. In days hopefully. And of course, thanks for your work!
Sunday, October 11, 2015, 5:35:20 PM, Woonsan Ko wrote:
> Hi Daniel,
>
> I figured out why the tests failed. HFS+ on OS X is not case-sensitive
> (but case-preserving) and the ast representation (on my env) seems to
> include newline literals ("\\r\\n"), but the expectation file contains
> only "\\n".
> Please see my comments in
> https://issues.apache.org/jira/browse/FREEMARKER-3 and review the PR.
>
> Thanks,
>
> Woonsan
>
>
> On Sun, Oct 11, 2015 at 8:57 PM, Woonsan Ko wrote:
>> On Sun, Oct 11, 2015 at 5:48 PM, Daniel Dekany wrote:
>>> Sunday, October 11, 2015, 4:56:34 AM, Woonsan Ko wrote:
>>>
>>>> Hi,
>>>>
>>>> When I added a new unit test, `ant test' seems failing in many test
>>>> classes. e.g, FileTemplateLoaderTest, etc.
>>>
>>> Maybe you ran into bugs in the test suite itself then. They are
>>> supposed to pass without doing anything special. I have only ever ran
>>> the test suite on Windows, and that's perhaps where the difference
>>> lies. They also must be all green if you ran them from Eclipse (or
>>> IntelliJ, etc.), and that's how I do it most of the time, since it's
>>> easier to navigate to errors, etc. You don't need the command line
>>> except for running JavaCC once (or after you have changed FTL.jj), and
>>> perhaps before a pull request to see if you have accidentally used a
>>> non-Java 5 API.
>>
>> I sometimes run unit test in IDE, but I also like running all the unit
>> tests in the command line. :-) That also helps continuous integration.
>> I didn't add any non-Java 5 compatible API usages in my PR. Also the
>> current ant build.xml enforces Java 1.5 in compile tasks already.
>>
>>>
>>> Anyway, can you look at the concrete errors to see if they are
>>> environment dependencies?
>>
>> Looks like environment related issue. When I run `ant test', it stops
>> after testing FileTemplateLoaderTest, and error is:
>>
>> junit.framework.AssertionFailedError
>> at
>> freemarker.cache.FileTemplateLoaderTest.testCaseSensitivity(FileTemplateLoaderTest.java:101)
>>
>> I'm not sure if OSX behaves like Windows somehow when resolving a file
>> or if this is something else yet.
>> I also tried it after excluding FileTemplateLoaderTest, but there are
>> other tests failing..
>> Anyway, I stopped there for now because this is not related to my pull
>> request. ;-) I'll look into the unit test issues later.
>>
>>>
>>>> So, I had to change build.xml (in batchtest task) to include only my
>>>> new test class locally.
>>>
>>> At least in Eclipse I can just right click on a package or class or
>>> method, and run it as JUnit test. (Then F11 to re-run it.)
>>>
>>>> My dev env is Ant 1.9.6 (Ivy 2.4.0) and JDK 1.8 on OSX.
>>>
>>> JDK 1.8 64 bit, 1.8.1, Windows 7 here... but if this matters, then
>>> that should be fixed.
>>>
>>>> How can I run all the unit tests successfully?
>>>> Also, is there any tip to run single unit test in command line (like
>>>> `mvn test -Dtest=...')?
>>>
>>> I think there was, but I don't remember the exact syntax anymore. But
>>> using you IDE is more efficient anyway.
>>
>> I'm used to Maven and Maven plugins for Eclipse, where I was able to
>> run unit test in IDE easily. Ant/Ivy/Eclipse environment looks a bit
>> different to me. I need some more time to learn.
>>
>> By the way, IIRC, you mentioned in old ML that it's planned to migrate
>> to Maven some day. Is it right? If so, when do you want to do that?
>>
>> Kind regards,
>>
>> Woonsan
>>
>>>
>>>> Thanks in advance,
>>>>
>>>> Woonsan
>>>>
>>>
>>> --
>>> Thanks,
>>> Daniel Dekany
>>>
>
--
Thanks,
Daniel Dekany
Re: Freemarker manual Local set up
With an example:
Template:
<#assign n = doc.r.b>
${n['preceding-sibling::*']}
${n['following-sibling::*']}
Data model:
doc=aaabbbccc
Result:
aaa
ccc
Monday, October 12, 2015, 10:29:24 AM, Pradeep Murugesan wrote:
> Hi Daniel,
> So this is where I am struck.
> In the ProgramListing macro I need to check if the current role is
> template and if it has a immediate previous sibling with role
> frm-dataModel . If so I will generate our hidden form elements and a visible
> "Try it out" button.
> http://freemarker.org/docs/xgui.html
> I read through this already, but I was not able to find any node
> build-ins to navigate to my immediate previous node, I mean it has
> pointers to go to a parent or child. But in this case I want to
> navigate to my preceding sibling right ?
> Kindly let me know If I am missing something.
> Pradeep.
>> Date: Sun, 11 Oct 2015 19:40:49 +0200
>> From: ddek...@freemail.hu
>> To: dev@freemarker.incubator.apache.org
>> Subject: Re: Freemarker manual Local set up
>>
>> I'm not sure where exactly you stuck, but I try to give some pointers.
>> Read http://freemarker.org/docs/xgui.html if you haven't. As you will
>> see there, you got the current XML node as .node in the programlisting
>> macro, and you can move around in the DOM tree from there, like
>> examine the previous/next programlisting, etc.
>>
>> As of shrinking the content, certainly you should work with a
>> minimalistic docbook. I don't know what error you get. (Of course the
>> XML must be well-formed XDocBook.)
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>>
>> Sunday, October 11, 2015, 5:50:06 PM, Pradeep Murugesan wrote:
>>
>> > Hi Daniel,
>> > I am still trying to knock it down but in vain. I dig down to
>> > programListing macro in NodeHandlers.ftlh and I am lost there as what is
>> > going on.
>> > I tried to shrink the content in book.xml and ran docgen to
>> > understand where do i need to inject the logic but that approach threw few
>> > other errors.
>> >
>> > It comes all the way down to generateHTMLFile_inner where we get
>> > page.fthl and process it and I am not able to proceed further.
>> > Could you please give me a clue ?
>> > Pradeep.
>> >> From: pradeepmuruge...@outlook.com
>> >> To: dev@freemarker.incubator.apache.org
>> >> Subject: RE: Freemarker manual Local set up
>> >> Date: Mon, 5 Oct 2015 14:45:09 +0530
>> >>
>> >> Hi Daniel,
>> >>
>> >> I am going through the docgen code and its taking some time to clearly
>> >> get what is happening in the Transform.java.
>> >> I am tracing down to the part where to check if the previous node is
>> >> frmDataModel if the current node is Template so that I have a hidden form
>> >> and try it out button. I am facing some challenges there.
>> >> I will try to complete things within this week.
>> >> Pradeep.
>> >>
>> >> > Date: Tue, 29 Sep 2015 21:45:41 +0200
>> >> > From: ddek...@freemail.hu
>> >> > To: pradeepmuruge...@outlook.com
>> >> > CC: dev@freemarker.incubator.apache.org
>> >> > Subject: Re: Freemarker manual Local set up
>> >> >
>> >> > FM is *built* with JDK 8 (and runs on Java 5+ as of 2.3.24). This
>> >> > information was missing from the README.txt... I have fixed that now.
>> >> > The important thing is to ensure that Ant runs on JDK 8 too. Perhaps
>> >> > you need to adjust the JAVA_HOME environment variable for that.
>> >> > (Clearing the Ivy or Ant directories is not needed.)
>> >> >
>> >> >
>> >> > Tuesday, September 29, 2015, 8:56:44 PM, Pradeep Murugesan wrote:
>> >> >
>> >> > > Tried upgrading to java 1.8 and cleared the ant and ivy cache.
>> >> > > still facing the same issue. Have any of you guys faced this already
>> >> > > Pradeep.
>> >> > >
>> >> > >> From: pradeepmuruge...@outlook.com
>> >> > >> To: dev@freemarker.incubator.apache.org
>> >> > >> Subject: RE: Freemarker manual Local set up
>> >> > >> Date: Tue, 29 Sep 2015 08:43:05 +0530
>> >> > >>
>> >> > >> Hi, I tried to do "ant manualFreemarkerOrg" to bring up the manual
>> >> > >> locally.
&
Re: Freemarker manual Local set up
Tuesday, October 13, 2015, 7:27:18 PM, Pradeep Murugesan wrote:
> Hi Daniel,
> Thanks for your pointers, Now I have figured out a way to check
> if the immediate previous node has a role 'formDataModel'.
>
> <#local siblingSize = .node['preceding-sibling::*']?size>
> <#local prevSibling = .node['preceding-sibling::*'][siblingSize-1]>
> <#local siblingRole = prevSibling.@role[0]!?string>
Those 3 lines could be written like this:
<#local siblingRole = .node['preceding-sibling::*[1]'].@role[0]!>
> ${siblingRole}
> <#if role == "template" && siblingRole == "formDataModel">...
> once I did the above, I googled to check what is
> "preceding-sibling" and understood that is Xpath terminology. I hope
> there should be a cleaner way than above to get the immediate
> preceding-sibling which I will try to find out.
We could add a built-in for it. The XPath way is not exactly
obvious...
> BTW, what are all the templates we have to add the dataModel. We need to do
> it for all ?
You mean, what if a template doesn't need a data model. I guess for
now then we add an empty data-model programlisting...
> Pradeep.
>> Date: Tue, 13 Oct 2015 01:59:30 +0200
>> From: ddek...@freemail.hu
>> To: dev@freemarker.incubator.apache.org
>> Subject: Re: Freemarker manual Local set up
>>
>> With an example:
>>
>> Template:
>> <#assign n = doc.r.b>
>> ${n['preceding-sibling::*']}
>> ${n['following-sibling::*']}
>>
>> Data model:
>> doc=aaabbbccc
>>
>> Result:
>> aaa
>> ccc
>>
>> Monday, October 12, 2015, 10:29:24 AM, Pradeep Murugesan wrote:
>>
>> > Hi Daniel,
>> > So this is where I am struck.
>> > In the ProgramListing macro I need to check if the current role is
>> > template and if it has a immediate previous sibling with role
>> > frm-dataModel . If so I will generate our hidden form elements and a
>> > visible "Try it out" button.
>> > http://freemarker.org/docs/xgui.html
>> > I read through this already, but I was not able to find any node
>> > build-ins to navigate to my immediate previous node, I mean it has
>> > pointers to go to a parent or child. But in this case I want to
>> > navigate to my preceding sibling right ?
>> > Kindly let me know If I am missing something.
>> > Pradeep.
>> >> Date: Sun, 11 Oct 2015 19:40:49 +0200
>> >> From: ddek...@freemail.hu
>> >> To: dev@freemarker.incubator.apache.org
>> >> Subject: Re: Freemarker manual Local set up
>> >>
>> >> I'm not sure where exactly you stuck, but I try to give some pointers.
>> >> Read http://freemarker.org/docs/xgui.html if you haven't. As you will
>> >> see there, you got the current XML node as .node in the programlisting
>> >> macro, and you can move around in the DOM tree from there, like
>> >> examine the previous/next programlisting, etc.
>> >>
>> >> As of shrinking the content, certainly you should work with a
>> >> minimalistic docbook. I don't know what error you get. (Of course the
>> >> XML must be well-formed XDocBook.)
>> >>
>> >> --
>> >> Thanks,
>> >> Daniel Dekany
>> >>
>> >>
>> >> Sunday, October 11, 2015, 5:50:06 PM, Pradeep Murugesan wrote:
>> >>
>> >> > Hi Daniel,
>> >> > I am still trying to knock it down but in vain. I dig down to
>> >> > programListing macro in NodeHandlers.ftlh and I am lost there as what
>> >> > is going on.
>> >> > I tried to shrink the content in book.xml and ran docgen to
>> >> > understand where do i need to inject the logic but that approach threw
>> >> > few other errors.
>> >> >
>> >> > It comes all the way down to generateHTMLFile_inner where we get
>> >> > page.fthl and process it and I am not able to proceed further.
>> >> > Could you please give me a clue ?
>> >> > Pradeep.
>> >> >> From: pradeepmuruge...@outlook.com
>> >> >> To: dev@freemarker.incubator.apache.org
>> >> >> Subject: RE: Freemarker manual Local set up
>> >> >> Date: Mon, 5 Oct 2015 14:45:09 +0530
>> >> >>
>> >> >> Hi Daniel,
>> >> >>
>> >> >> I am going through th
Re: Number format configuration option
There are substantial new features in the upcoming release (2.3.24)
regarding formatting, though their purpose is adding new
functionality, rather than streamlining configuration (which is what
you aim for, if I understand well), which you usually only do once or
so.
If you check out the head (the 2.3-gae or 2.3 branch preferably),
there's something called freemarker.core.TemplateNumberFormat and
freemarker.core.TemplateDateFormat. These are similar in purpose to
Java's NumberFormat and DateFormat, but are specialized for the
requirements of FreeMarker.
But, you can't specify these directly in the configuration. The
numberFormat and dateFormat etc. settings are still strings, because
lot of already existing functionality builds on that (like
foo?string("#.###")), and also because you can't really "overload" a
setting since it has both a setter and a getter side. So there's a
customNumberFormats (of type Map) and a customDateFormats (of type
Map) setting, with which
you can register your own formatters, and then refer to them like
setNumberFormat("@myFormat") or even setNumberFormat("@myFormat some
params that it will parse"). So that's how it goes; a bit of
indirection. This new feature has two main points. One is that now you
can write your own formatters in Java, and you aren't forced to use
DecimalFormat and SimpleDateFormat anymore, which were often limiting.
The other is that you can use application domain format names like
"@price", "@coordinate", etc., and then control outside the templates
how a "price" or a "coordinate" looks. And actually, there's a third
smaller point, that as now the formatter has access to the
TemplateModel, it can decide the format depending on the meaning of
the number, like automatically show units next to it, if you put the
necessary information into your data model. And there's even a fourth
point, that now a formatter can choose to output markup (like HTML)
instead of plain text.
So that's what we have in 2.3.24 now, which I hope will be released
this year. If you can start using it and give feedback, like report
rough edges and bugs, that's a big help.
--
Thanks,
Daniel Dekany
Tuesday, October 13, 2015, 4:38:39 PM, Eduard Valiauka wrote:
> Hello, folks
>
> In our project we are using freemarker to process dynamic(written by users)
> templates.
> So, our code related to template processing looks like the following:
>
> Configuration configuration = new Configuration();
> configuration.setLocale(locale);
> new Template("name", template, configuration).process(data, stringWriter);
>
> Our requirements for processing output are
> 1. Number formatting should be localized
> 2. Fraction digits should never be cut. That means that 1.12345 should not
> be displayed as 1.123. This happens because default value for
> NumberFormat#maxFractionDigits is 3
>
> We ended up by setting the following configuration option
> conf.setNumberFormat("###,###.");
>
> But I personally feel that working with format patterns is a bit
> counter-intuitive and error-prone.
> I would prefer the following:
>
> NumberFormat numberFormat = NumberFormat.getNumberInstance(locale);
> numberFormat.setMaximumFractionDigits(Integer.MAX_VALUE);
> configuration.setNumberFormat(numberFormat);
>
> But setNumberFormat only accepts strings.
> Looking at the source of freemarker.core.Environment it does not look like
> a huge change to provide a method that would accept an instance of
> NumberFormat.
>
> Do you guys already have plans for implemenation of this change? I would
> really appreciate having this functionality.
>
>
>
>
> Thank you for your time,
> Eduard
Re: template inclusions cause stackoverflowerror
Thanks, I will review it more closely as soon as I get to it... like there's a slight hope that it will happen this weekend. Others, please look at this patch and tell your opinions, if you find the time! As of me, I have finally decided to let this change in (unless I will find some new issue I haven't realized yet). Wednesday, October 14, 2015, 2:35:40 PM, Kleine, Moritz wrote: > Hi, here¹s the 2.3-gae pull request > https://github.com/apache/incubator-freemarker/pull/6 > Regards, > Moritz > > On 9/11/15, 7:49 PM, "Daniel Dekany" wrote: > >>It surely consumes less stack this way, though stack usage doesn't >>used to be an concern (barring FTL sequence concatenations in a loop, >>but that's another topic). While less stack is just better regardless, >>with this change the code becomes a bit more convoluted (especially if >>you had to do something after the child elements ran; though if I saw >>well, surprisingly, we don't have such case so far). So I would like >>to understand why does your application need so deep stack. I would >>think that you had to have some ridiculously high number of things >>nested into each other to run into this, but maybe I'm wrong. >> >> >>Thursday, September 10, 2015, 3:53:13 PM, Kleine, Moritz wrote: >> >>> Hi, >>> >>> we¹re building a website using a view-agnostic document store and a >>> spring-based webapp that is capable of rendering views for documents >>> that include views of linked documents. The views are typically >>> small freemarker templates (at most some tenths of lines) using a >>> custom include directive that determines the view for the included >>> document and if it is a freemarker template ‹ tells that template to >>>process itself. >>> >>> Now, we¹re frequently running into stackoverflowerrors which >>> exhibit the level of inclusion and the whole structure of the >>> freemarker templates from the root of up to the custom include. The >>> stacktrace fragment shown below ([1]) is taken from such a >>> stackoverflowerror. I¹d suggest to adjust the visitor pattern based >>> implementation so that the accept calls do not invoke >>> Environment#visit again but return the tempate elements to be >>> visited. That way we obtain stacktraces that look as shown further >>> down below ([2]). The patched code resides here: >>> >>>https://github.com/mkleine/incubator-freemarker/tree/avoid-too-much-recur >>>sion-when-visiting-template-elements >>> >>> Are we misusing freemarker or is the approach to reduction of >>>stackframes welcome? >>> >>> Kind regards, >>> Moritz >>> >>> >>> [1] >>> at >>> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458) >>>[freemarker-2.3.22.jar:2.3.22] >>> at >>> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:71) >>>[freemarker-2.3.22.jar:2.3.22] >>> at freemarker.core.MethodCall._eval(MethodCall.java:62) >>>[freemarker-2.3.22.jar:2.3.22] >>> at freemarker.core.Expression.eval(Expression.java:78) >>>[freemarker-2.3.22.jar:2.3.22] >>> at >>> freemarker.core.Expression.evalAndCoerceToString(Expression.java:82) >>>[freemarker-2.3.22.jar:2.3.22] >>> at >>> freemarker.core.BuiltInForString._eval(BuiltInForString.java:26) >>>[freemarker-2.3.22.jar:2.3.22] >>> at freemarker.core.Expression.eval(Expression.java:78) >>>[freemarker-2.3.22.jar:2.3.22] >>> at >>> freemarker.core.Expression.evalAndCoerceToString(Expression.java:82) >>>[freemarker-2.3.22.jar:2.3.22] >>> at >>> freemarker.core.DollarVariable.accept(DollarVariable.java:40) >>>[freemarker-2.3.22.jar:2.3.22] >>> at freemarker.core.Environment.visit(Environment.java:312) >>>[freemarker-2.3.22.jar:2.3.22] >>> at >>> freemarker.core.MixedContent.accept(MixedContent.java:62) >>>[freemarker-2.3.22.jar:2.3.22] >>> at >>> freemarker.core.Environment.visitByHiddingParent(Environment.java:333) >>>[freemarker-2.3.22.jar:2.3.22] >>> at >>> freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:48) >>>[freemarker-2.3.22.jar:2.3.22] >>> at >>> freemarker.core.Environment.visitByHiddingParent(Environment.java:333) >>>[freemarker-2.3.22.jar:2.3.22] >>> at >>>
Re: Adding a new BuiltIn - previousSibling
I'm not sure what's improper in the result (I don't know what was
expected). Isn't that node preceded by white space? That would explain
it. You might rather want the previous *element*. But that will be
difficult to express on the TemplateNodeModel level, which is not
bound to XML.
One important point is that you can't add new methods to
TemplateNodeModel, as that breaks backward compatibility. It can only
be added to a new sub-interface, like TemplateNodeModelEx. But even
that won't solve getting the sibling element node.
So another approach is instead of adding a built-in, adding a new
special key that's specific to freemarker.ext.dom models, like
"@@prev" and "@@next".
--
Thanks,
Daniel Dekany
Wednesday, October 14, 2015, 9:10:25 PM, Pradeep Murugesan wrote:
> Hi Daniel,
> I tried to add a new built in & of course it DIDN'T work �.
> I did the following.
> 1. added putBI("previousSibling", new previousSiblingBI()); in
> BuiltIn.java2. added a static class in BuiltInForNodes.java static
> class previousSiblingBI extends BuiltInForNode {
>
>
>
>
>
>
>
>
> @Override
> TemplateModel calculateResult(TemplateNodeModel nodeModel,
> Environment env) throws TemplateModelException {
> return nodeModel.getPreviousSibling();
> }
>}
> 3. added a method in Interface TemplateNodeModel.java
>
>
>
>
>
>
>
> TemplateNodeModel getPreviousSibling() throws TemplateModelException;
> 4. In package freemarker.ext.dom's NodeModel added the following method
>
>
>
>
>
>
>
>
> public TemplateNodeModel getPreviousSibling() { Node
> previousSibling = node.getPreviousSibling();
>
>
>
>
>
>
>
>
> return wrap(previousSibling);}
> Once this is done I tried to access it as .node?previousSibling
> from template and it reached till the NodeModel class i defined in
> the 4th step. But the returned previousSibling is not proper. It's
> not returning the programListingNode with formDataModel instead returns
> someother node.
> I tried to log the node returned and I got the following o/p
> [docgen:transform] [#text:
>
>
>
>
>
>
>
>
> [docgen:transform] ]
> I clearly understand the implementation of getPreviousSibling is
> not proper, but I couldn't figure out where we have implemented the same.
> Please advise.
> Pradeep.
>
>
>
>
>
>
>
>
Re: Adding a new BuiltIn - previousSibling
Thursday, October 15, 2015, 4:13:18 PM, Pradeep Murugesan wrote:
> HI Daniel,
> Its not preceeded by white spaces but "\n" is taken as sibling.
\n is whitespace, and it's a sibling in XML.
> In book.xml dsadsd fdfsdfdsf
> dfds
> <#if cargo.weight <
> 100>Light cargo</#if>
> I am trying to get the programlisting with role formDataModel as
> previousSibling. But the "\n" is returned as the sibling. To confirm
> the same I just checked it with
> node.previousSibling().previousSibling() and I am able to get to
> formDataModel.
> What should we need to do for this here ?
Nothing... it's correct that way. it's that you want the sibling
*element*, as I said. Actually, it's a bit trickier than that. You
want to get the sibling element, unless the interfering character data
is non-whitespace. Because, if you have cdata, then surely you
don't want to say that is preceded bu , but "cdata".
> I have also added a key with @@prev in ElementModel and that works fine.
So what exactly is the semantic of @@prev?
> Pradeep.
>> Date: Wed, 14 Oct 2015 22:32:40 +0200
>> From: ddek...@freemail.hu
>> To: dev@freemarker.incubator.apache.org
>> Subject: Re: Adding a new BuiltIn - previousSibling
>>
>> I'm not sure what's improper in the result (I don't know what was
>> expected). Isn't that node preceded by white space? That would explain
>> it. You might rather want the previous *element*. But that will be
>> difficult to express on the TemplateNodeModel level, which is not
>> bound to XML.
>>
>> One important point is that you can't add new methods to
>> TemplateNodeModel, as that breaks backward compatibility. It can only
>> be added to a new sub-interface, like TemplateNodeModelEx. But even
>> that won't solve getting the sibling element node.
>>
>> So another approach is instead of adding a built-in, adding a new
>> special key that's specific to freemarker.ext.dom models, like
>> "@@prev" and "@@next".
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>>
>> Wednesday, October 14, 2015, 9:10:25 PM, Pradeep Murugesan wrote:
>>
>> > Hi Daniel,
>> > I tried to add a new built in & of course it DIDN'T work �.
>> > I did the following.
>> > 1. added putBI("previousSibling", new previousSiblingBI()); in
>> > BuiltIn.java2. added a static class in BuiltInForNodes.java static
>> > class previousSiblingBI extends BuiltInForNode {
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > @Override
>> > TemplateModel calculateResult(TemplateNodeModel nodeModel,
>> > Environment env) throws TemplateModelException {
>> > return nodeModel.getPreviousSibling();
>> > }
>> >}
>> > 3. added a method in Interface TemplateNodeModel.java
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > TemplateNodeModel getPreviousSibling() throws TemplateModelException;
>> > 4. In package freemarker.ext.dom's NodeModel added the following method
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > public TemplateNodeModel getPreviousSibling() { Node
>> > previousSibling = node.getPreviousSibling();
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > return wrap(previousSibling);}
>> > Once this is done I tried to access it as .node?previousSibling
>> > from template and it reached till the NodeModel class i defined in
>> > the 4th step. But the returned previousSibling is not proper. It's
>> > not returning the programListingNode with formDataModel instead returns
>> > someother node.
>> > I tried to log the node returned and I got the following o/p
>> > [docgen:transform] [#text:
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > [docgen:transform] ]
>> > I clearly understand the implementation of getPreviousSibling is
>> > not proper, but I couldn't figure out where we have implemented the same.
>> > Please advise.
>> > Pradeep.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>
--
Thanks,
Daniel Dekany
Re: Adding a new BuiltIn - previousSibling
Thursday, October 15, 2015, 10:44:10 PM, Pradeep Murugesan wrote:
> Hi Daniel,
> So you are saying we need to have it that way and leave the
> responsibility to the caller. Lets say in case of us to get to check
> if template is preceded by formDataModel we will do the follwing ?
> <#local siblingElement = .node.@@prev.@@prev>
> then check the role attribute of siblingElement ?
> I assume the semantic for @@prev should return the immediate
> sibling being it a whitespace , CDATA or \n as in our case.
> Let me know your thoughts.
I think that in almost all cases the user means the previous DOM node
ignoring white-space nodes and comments, and certainly PI-s too.
(That's also why ?previous or such wouldn't solve the problem you ran
into, while it can be still very useful in some other applications,
like where the tree is not from XML but something less
document-centric.) (Non-normalized DOM-s, like one with sibling cdata
nodes, could also complicate what we need, but I belive that such
cases can only be addressed reasonably be ensuring that the whole DOM
is normalized before we do anything with it... so it doesn't mater
now.)
> Pradeep.
>> Date: Thu, 15 Oct 2015 20:32:33 +0200
>> From: ddek...@freemail.hu
>> To: dev@freemarker.incubator.apache.org
>> Subject: Re: Adding a new BuiltIn - previousSibling
>>
>> Thursday, October 15, 2015, 4:13:18 PM, Pradeep Murugesan wrote:
>>
>> > HI Daniel,
>> > Its not preceeded by white spaces but "\n" is taken as sibling.
>>
>> \n is whitespace, and it's a sibling in XML.
>>
>> > In book.xml dsadsd fdfsdfdsf
>> > dfds
>> > <#if cargo.weight <
>> > 100>Light cargo</#if>
>> > I am trying to get the programlisting with role formDataModel as
>> > previousSibling. But the "\n" is returned as the sibling. To confirm
>> > the same I just checked it with
>> > node.previousSibling().previousSibling() and I am able to get to
>> > formDataModel.
>> > What should we need to do for this here ?
>>
>> Nothing... it's correct that way. it's that you want the sibling
>> *element*, as I said. Actually, it's a bit trickier than that. You
>> want to get the sibling element, unless the interfering character data
>> is non-whitespace. Because, if you have cdata, then surely you
>> don't want to say that is preceded bu , but "cdata".
>>
>> > I have also added a key with @@prev in ElementModel and that works fine.
>>
>> So what exactly is the semantic of @@prev?
>>
>> > Pradeep.
>> >> Date: Wed, 14 Oct 2015 22:32:40 +0200
>> >> From: ddek...@freemail.hu
>> >> To: dev@freemarker.incubator.apache.org
>> >> Subject: Re: Adding a new BuiltIn - previousSibling
>> >>
>> >> I'm not sure what's improper in the result (I don't know what was
>> >> expected). Isn't that node preceded by white space? That would explain
>> >> it. You might rather want the previous *element*. But that will be
>> >> difficult to express on the TemplateNodeModel level, which is not
>> >> bound to XML.
>> >>
>> >> One important point is that you can't add new methods to
>> >> TemplateNodeModel, as that breaks backward compatibility. It can only
>> >> be added to a new sub-interface, like TemplateNodeModelEx. But even
>> >> that won't solve getting the sibling element node.
>> >>
>> >> So another approach is instead of adding a built-in, adding a new
>> >> special key that's specific to freemarker.ext.dom models, like
>> >> "@@prev" and "@@next".
>> >>
>> >> --
>> >> Thanks,
>> >> Daniel Dekany
>> >>
>> >>
>> >> Wednesday, October 14, 2015, 9:10:25 PM, Pradeep Murugesan wrote:
>> >>
>> >> > Hi Daniel,
>> >> > I tried to add a new built in & of course it DIDN'T work �.
>> >> > I did the following.
>> >> > 1. added putBI("previousSibling", new previousSiblingBI()); in
>> >> > BuiltIn.java2. added a static class in BuiltInForNodes.java static
>> >> > class previousSiblingBI extends BuiltInForNode {
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > @Override
>> >> > Template
Re: Adding a new BuiltIn - previousSibling
Saturday, October 17, 2015, 7:09:49 PM, Pradeep Murugesan wrote: > hmm then I think @@prev should return the immediate sibling with the > following issues/advantages. > 1. In xml doc its a overhead for user to call it twice to get the > previous element node2. It much worse than that, if it just returns the previous sibling on the DOM, as you can't know if you have to call it once, twice, 3 times, etc. > For less document centric it is not a problem. For non-document XML it's similarly desirable. I meant JSON and such, where @@prev doesn't exist anyway... > 3. for Non-normalized dom we wont do anything before they normalize it . Actually, we can do a little effort... skipping *all* the white-space-only character date nodes and comments and PI-s. But that's all. > Let me know If I got that correctly. > If so I will add @@prev as a special case and use > .node.@@prev.@@prev to get to theprevious sibling node. You mean, you will use: .node.@@prev > Pradeep. > >> Date: Fri, 16 Oct 2015 01:09:36 +0200 >> From: ddek...@freemail.hu >> To: dev@freemarker.incubator.apache.org >> Subject: Re: Adding a new BuiltIn - previousSibling >> >> Thursday, October 15, 2015, 10:44:10 PM, Pradeep Murugesan wrote: >> >> > Hi Daniel, >> > So you are saying we need to have it that way and leave the >> > responsibility to the caller. Lets say in case of us to get to check >> > if template is preceded by formDataModel we will do the follwing ? >> > <#local siblingElement = .node.@@prev.@@prev> >> > then check the role attribute of siblingElement ? >> > I assume the semantic for @@prev should return the immediate >> > sibling being it a whitespace , CDATA or \n as in our case. >> > Let me know your thoughts. >> >> I think that in almost all cases the user means the previous DOM node >> ignoring white-space nodes and comments, and certainly PI-s too. >> (That's also why ?previous or such wouldn't solve the problem you ran >> into, while it can be still very useful in some other applications, >> like where the tree is not from XML but something less >> document-centric.) (Non-normalized DOM-s, like one with sibling cdata >> nodes, could also complicate what we need, but I belive that such >> cases can only be addressed reasonably be ensuring that the whole DOM >> is normalized before we do anything with it... so it doesn't mater >> now.) >> >> > Pradeep. >> >> Date: Thu, 15 Oct 2015 20:32:33 +0200 >> >> From: ddek...@freemail.hu >> >> To: dev@freemarker.incubator.apache.org >> >> Subject: Re: Adding a new BuiltIn - previousSibling >> >> >> >> Thursday, October 15, 2015, 4:13:18 PM, Pradeep Murugesan wrote: >> >> >> >> > HI Daniel, >> >> > Its not preceeded by white spaces but "\n" is taken as sibling. >> >> >> >> \n is whitespace, and it's a sibling in XML. >> >> >> >> > In book.xml dsadsd fdfsdfdsf >> >> > dfds >> >> > <#if cargo.weight < >> >> > 100>Light cargo</#if> >> >> > I am trying to get the programlisting with role formDataModel as >> >> > previousSibling. But the "\n" is returned as the sibling. To confirm >> >> > the same I just checked it with >> >> > node.previousSibling().previousSibling() and I am able to get to >> >> > formDataModel. >> >> > What should we need to do for this here ? >> >> >> >> Nothing... it's correct that way. it's that you want the sibling >> >> *element*, as I said. Actually, it's a bit trickier than that. You >> >> want to get the sibling element, unless the interfering character data >> >> is non-whitespace. Because, if you have cdata, then surely you >> >> don't want to say that is preceded bu , but "cdata". >> >> >> >> > I have also added a key with @@prev in ElementModel and that works fine. >> >> >> >> So what exactly is the semantic of @@prev? >> >> >> >> > Pradeep. >> >> >> Date: Wed, 14 Oct 2015 22:32:40 +0200 >> >> >> From: ddek...@freemail.hu >> >> >> To: dev@freemarker.incubator.apache.org >> >> >> Subject: Re: Adding a new BuiltIn - previousSibling >> >> >> >> >> >> I'm not sure what's improper in the result (I don't know what was >> >> >&g
Re: Adding a new BuiltIn - previousSibling
Returning the sibling node without skipping stuff is not XML-specific, so certainly that should be ?previous (and a new method in the new TemplateNodeModelEx interface), not a hash key that starts with "@". BTW, of course all of these has an opposite direction variant, like "@next". And "@prev" may should be "@previous". -- Thanks, Daniel Dekany Sunday, October 18, 2015, 5:31:50 AM, Pradeep Murugesan wrote: > yeah makes sense.. > so we need to return a valid element node he is looking for > skipping all the whitespace, CDATA etc... > I am wondering if the user will have any reason to look for a CDATA > sibling or any non element sibling which we will skip. > In that case can we have 2 special cases. > 1. @prev which will return the immediate sibling2. @prevNode or > something intutive which will return a valid element skipping few . > Pradeep. >> Date: Sat, 17 Oct 2015 20:15:57 +0200 >> From: ddek...@freemail.hu >> To: dev@freemarker.incubator.apache.org >> Subject: Re: Adding a new BuiltIn - previousSibling >> >> Saturday, October 17, 2015, 7:09:49 PM, Pradeep Murugesan wrote: >> >> > hmm then I think @@prev should return the immediate sibling with the >> > following issues/advantages. >> > 1. In xml doc its a overhead for user to call it twice to get the >> > previous element node2. >> >> It much worse than that, if it just returns the previous sibling on >> the DOM, as you can't know if you have to call it once, twice, 3 >> times, etc. >> >> > For less document centric it is not a problem. >> >> For non-document XML it's similarly desirable. I meant JSON and such, >> where @@prev doesn't exist anyway... >> >> > 3. for Non-normalized dom we wont do anything before they normalize it . >> >> Actually, we can do a little effort... skipping *all* the >> white-space-only character date nodes and comments and PI-s. But >> that's all. >> >> > Let me know If I got that correctly. >> > If so I will add @@prev as a special case and use >> > .node.@@prev.@@prev to get to theprevious sibling node. >> >> You mean, you will use: .node.@@prev >> >> > Pradeep. >> > >> >> Date: Fri, 16 Oct 2015 01:09:36 +0200 >> >> From: ddek...@freemail.hu >> >> To: dev@freemarker.incubator.apache.org >> >> Subject: Re: Adding a new BuiltIn - previousSibling >> >> >> >> Thursday, October 15, 2015, 10:44:10 PM, Pradeep Murugesan wrote: >> >> >> >> > Hi Daniel, >> >> > So you are saying we need to have it that way and leave the >> >> > responsibility to the caller. Lets say in case of us to get to check >> >> > if template is preceded by formDataModel we will do the follwing ? >> >> > <#local siblingElement = .node.@@prev.@@prev> >> >> > then check the role attribute of siblingElement ? >> >> > I assume the semantic for @@prev should return the immediate >> >> > sibling being it a whitespace , CDATA or \n as in our case. >> >> > Let me know your thoughts. >> >> >> >> I think that in almost all cases the user means the previous DOM node >> >> ignoring white-space nodes and comments, and certainly PI-s too. >> >> (That's also why ?previous or such wouldn't solve the problem you ran >> >> into, while it can be still very useful in some other applications, >> >> like where the tree is not from XML but something less >> >> document-centric.) (Non-normalized DOM-s, like one with sibling cdata >> >> nodes, could also complicate what we need, but I belive that such >> >> cases can only be addressed reasonably be ensuring that the whole DOM >> >> is normalized before we do anything with it... so it doesn't mater >> >> now.) >> >> >> >> > Pradeep. >> >> >> Date: Thu, 15 Oct 2015 20:32:33 +0200 >> >> >> From: ddek...@freemail.hu >> >> >> To: dev@freemarker.incubator.apache.org >> >> >> Subject: Re: Adding a new BuiltIn - previousSibling >> >> >> >> >> >> Thursday, October 15, 2015, 4:13:18 PM, Pradeep Murugesan wrote: >> >> >> >> >> >> > HI Daniel, >> >> >> > Its not preceeded by white spaces but "\n" is taken as sibling. >> >> >> >> >> >> \n is whitespace, and it's a sibling in XML.
Proposal: Extended FreemarkerServlet response Content-type and charset logic (Was: Re: Just created content-type and locale issues in JIRA)
So I have merged this
(https://issues.apache.org/jira/browse/FREEMARKER-1) in, but while
reviewing the stuff, I have realized that I'm not sure how exactly
this should work, especially as OutputFormat-s (the main 2.3.24
feature, mostly used for auto-escaping, but usually also specifies a
MIME type) comes into the picture. As far as I see, the most generic
solution would be this:
The new "OverrideResponseContentType" FreemarkerServlet init-param
(the topic of https://issues.apache.org/jira/browse/FREEMARKER-1)
could have three values:
- "always": We always set it to something (see later to what),
overriding and ignoring anything that was in
servletResponse.contentType. This is the backward compatible mode,
and so the default. I also believe that this happens to be good
default regardless of backward compatibility, because it's the
business of the MVC View to decide such things as the MIME type.
- "never": Never *overrides*, means if servletResponse.contentType
it null, it will still set it, like "always" does, otherwise it
just leaves servletResponse.contentType alone. This means that the
code that forwards to FreemarkerSerlvet has full control over the
servletResponse.contentType, if it cares to set it.
- "whenTemplateHasContentType": If either the legacy "content_type"
custom template attribute is present (usually set with <#ftl
attributes={"content_type": "..."}>), or the template has an
associated OutputFormat that specifies a non-null MIME type (usually
"text/html"), then we behave as "always", otherwise as "never". The
logic behind this is that if a template has an associated MIME Type,
then that's certainly correct and shouldn't trampled on.
Applications may will mix legacy templates with those with
associated OutputFormat, that's why the "never" branch has
importance.
So what does "always" set the content type to? We have a "ContentType"
FreemarkerServlet init-param since forever (defaulting to
"text/html"), and most often that's what we set it to. There's also an
old and obscure feature where you can specify a different one per
template via the "content_type" custom template attribute. But the
important new thing is that associating OutputFormat to each template
meant to become the norm in the future, and an OutputFormat usually
specifies a MIME type too. So we have a non-obscure mechanism to
figure out the content type for an *individual* template, starting
from 2.3.24. (Of course most applications won't set up OutputFormat
associations for a long time, and in that case templates are
associated to the "undefined" OutputFormat, that specifies no MIME
type, so we just get the old behavior.)
I have also realized that the way one can specify the output charset
with FreemarkerServlet is crude too. So I'm thinking about adding an
"ResponseCharacterEncoding" FreemarkerServlet init-param too. There
the most generic set of values would look like this:
- "legacy": Default for backward compatibility. Has some strange
quirks... It doesn't mater how it works now, as it's a legacy.
- "fromTemplate": We get the charset from template.getOutputEncoding(),
which is an optional setting existing for a good while. If that's
null, we use template.getEncoding(), which is the encoding of the
source file.
- "always ${charset}", like "always UTF-8": We just always set it to that,
via ServletResponse.setCharacterEncoding.
- "doNotSet": We just don't set it, ever. (We can't detect if it was
set in the ServletRequest by the forwared, so we can't be smarter, I
believe.)
A side note is that the modes other than "legacy" will need at least
Servlet 2.4, so that we will have
ServletResponse.setCharacterEncoding, instead of wresting with
appending it the charset to the contentType.
Comments, ideas? How does this fit your applications?
--
Thanks,
Daniel Dekany
Sunday, October 11, 2015, 4:43:13 AM, Woonsan Ko wrote:
> Hi,
>
> I've just created a PR for FREEMARKER-1:
> - https://github.com/apache/incubator-freemarker/pull/1
>
> I suppose that PR should be automatically posted here soon.
>
> Just for information, PRs on the github mirror can be applied in the
> way as explained in the "Applying Pull Requests (for git based
> components)" section [1].
>
> Cheers,
>
> Woonsan
>
> [1] https://wiki.apache.org/commons/UsingGIT
>
>
> On Fri, Oct 9, 2015 at 6:52 AM, Woonsan Ko wrote:
>> Hi folks,
>>
>> I've just created two JIRA issues:
>> - https://issues.apache.org/jira/browse/FREEMARKER-1
>> - https://issues.apache.org/jira/browse/FREEMARKER-2
>>
>> Yeah, number 1 and 2! :)
>>
>> Those were actually discussed in the old ML. I contracted those to the
>> two issues.
>> Hopefully I can create PRs and ask for review sooner or later.
>>
>> Thanks!
>>
>> Cheers,
>>
>> Woonsan
>
Re: Proposal: Extended FreemarkerServlet response Content-type and charset logic (Was: Re: Just created content-type and locale issues in JIRA)
Tuesday, October 20, 2015, 6:08:33 AM, Woonsan Ko wrote:
> Hi Daniel,
>
> Thanks a lot for the reasonable/thorough analysis and solutions!
> Yes, your proposal will solve our problem (FREEMARKER-1). We can
> probably set it to "never" in our default configuration.
>
> In our case, our MVC framework allows developers to set response
> content type to anything before dispatching to freemarker servlet. For
> example, they can set "text/html", "application/xml",
> "application/json", "application/vnd.api+json", or whatever they want
> to use. In that case, some developers prefers setting a content type
> in a controller with setting model beans (which can be written as
> string, html, xml or json string) in request attributes before
> dispatching to freemarker servlet.
> I understand it can be solved in different ways, but I'd like to
> support them with what they're allowed to by servlet specification.
> Your proposal with the different options seems fulfilling this.
OK, so that's how it will be, unless somebody else says something.
We may also need a protected getDefaultOverrideRequestContentType()
method, so that a subclass can change the default from "always".
Any comments about the output charset selection? How do you at Hippo
control that?
> By the way, regarding FREEMARKET-2, maybe do we need to have
> somethings similar for FreemarkerServlet#deduceLocale() with
> "OverrideResponseLocale" init-param? e.g, "always" and "never".
> "never" behaves like "always" if HttpServletRequest#getLocale()
> returns null.
So, OverrideResponseLocale "never" wouldn't even call deduceLocale()
if servletRequest.locale is non-null. Otherwise we call deduceLocale()
and use what it returns. A bit twisted in that an overridden
deduceLocale() could do all this alone (examine servletRequest.locale,
decide if it will override it), but I guess this is the most practical
compromise.
Note that for any of these init-params, even where right now we only
have two possible values, I prefer a string value over a boolean
because it's more future proof.
--
Thanks,
Daniel Dekany
> Regards,
>
> Woonsan
>
>
> On Mon, Oct 19, 2015 at 4:28 AM, Daniel Dekany wrote:
>> So I have merged this
>> (https://issues.apache.org/jira/browse/FREEMARKER-1) in, but while
>> reviewing the stuff, I have realized that I'm not sure how exactly
>> this should work, especially as OutputFormat-s (the main 2.3.24
>> feature, mostly used for auto-escaping, but usually also specifies a
>> MIME type) comes into the picture. As far as I see, the most generic
>> solution would be this:
>>
>> The new "OverrideResponseContentType" FreemarkerServlet init-param
>> (the topic of https://issues.apache.org/jira/browse/FREEMARKER-1)
>> could have three values:
>>
>> - "always": We always set it to something (see later to what),
>> overriding and ignoring anything that was in
>> servletResponse.contentType. This is the backward compatible mode,
>> and so the default. I also believe that this happens to be good
>> default regardless of backward compatibility, because it's the
>> business of the MVC View to decide such things as the MIME type.
>>
>> - "never": Never *overrides*, means if servletResponse.contentType
>> it null, it will still set it, like "always" does, otherwise it
>> just leaves servletResponse.contentType alone. This means that the
>> code that forwards to FreemarkerSerlvet has full control over the
>> servletResponse.contentType, if it cares to set it.
>>
>> - "whenTemplateHasContentType": If either the legacy "content_type"
>> custom template attribute is present (usually set with <#ftl
>> attributes={"content_type": "..."}>), or the template has an
>> associated OutputFormat that specifies a non-null MIME type (usually
>> "text/html"), then we behave as "always", otherwise as "never". The
>> logic behind this is that if a template has an associated MIME Type,
>> then that's certainly correct and shouldn't trampled on.
>> Applications may will mix legacy templates with those with
>> associated OutputFormat, that's why the "never" branch has
>> importance.
>>
>> So what does "always" set the content type to? We have a "ContentType"
>> FreemarkerServlet init-param since forever (defaulting to
>> "text/html"), and most often that's what we set it to. There's also an
>
Abandoning Servlet 2.3 support?
We will need to call some Servlet 2.4 API-s, and I can solve it reflection and such, and by complication the build.xml a bit further. I just wonder if it worths it. Here's a bit of Servlet history: Servlet 2.3 August 2001 J2EE 1.3, J2SE 1.2 JSP 1.2 Servlet 2.4 November 2003 J2EE 1.4, J2SE 1.3 JSP 2.0 Servlet 2.5 September 2005 JavaEE 5, JavaSE 5 JSP 2.1 2.3.24 has already raised minimum Java version to 5, and minimum JSP version to 2.0 (that's the pair of Servlet 2.4). These had to be done, pretty much. Requiring 2.4 is not a must have, but I wonder if keeping it worths the complication... -- Thanks, Daniel Dekany
Re: Proposal: Extended FreemarkerServlet response Content-type and charset logic (Was: Re: Just created content-type and locale issues in JIRA)
I have committed the OverrideResponseContentType
always/never/whenTemplateHasMimeType thing. (Also did some further
cleanup.) So update before you modify anything.
--
Thanks,
Daniel Dekany
Wednesday, October 21, 2015, 3:19:06 AM, Woonsan Ko wrote:
> On Wed, Oct 21, 2015 at 5:12 AM, Daniel Dekany wrote:
>> Tuesday, October 20, 2015, 6:08:33 AM, Woonsan Ko wrote:
>>
>>> Hi Daniel,
>>>
>>> Thanks a lot for the reasonable/thorough analysis and solutions!
>>> Yes, your proposal will solve our problem (FREEMARKER-1). We can
>>> probably set it to "never" in our default configuration.
>>>
>>> In our case, our MVC framework allows developers to set response
>>> content type to anything before dispatching to freemarker servlet. For
>>> example, they can set "text/html", "application/xml",
>>> "application/json", "application/vnd.api+json", or whatever they want
>>> to use. In that case, some developers prefers setting a content type
>>> in a controller with setting model beans (which can be written as
>>> string, html, xml or json string) in request attributes before
>>> dispatching to freemarker servlet.
>>> I understand it can be solved in different ways, but I'd like to
>>> support them with what they're allowed to by servlet specification.
>>> Your proposal with the different options seems fulfilling this.
>>
>> OK, so that's how it will be, unless somebody else says something.
>>
>> We may also need a protected getDefaultOverrideRequestContentType()
>> method, so that a subclass can change the default from "always".
>
> That would be nice!
>
>>
>> Any comments about the output charset selection? How do you at Hippo
>> control that?
>
> Mostly they have been okay with the default ContentType configuration
> as init param: "text/html; charset=UTF-8". This default configuration
> has fulfilled most of our use cases even if they want to control it in
> controllers in some cases. Also probably they are okay with UTF-8
> encoding in almost every case.
> All those options ("fromTemplate", "always ${charset}" and "doNotSet")
> seem like good options to choose. Personally speaking, due to nature
> of our HMVC (with which the top ancestor controller's template's
> contentType setting will win), I normally recommend our customers to
> set it globally, not from template in most cases, just to avoid
> confusions from the controller component hierarchy.
>
>>
>>> By the way, regarding FREEMARKET-2, maybe do we need to have
>>> somethings similar for FreemarkerServlet#deduceLocale() with
>>> "OverrideResponseLocale" init-param? e.g, "always" and "never".
>>> "never" behaves like "always" if HttpServletRequest#getLocale()
>>> returns null.
>>
>> So, OverrideResponseLocale "never" wouldn't even call deduceLocale()
>> if servletRequest.locale is non-null. Otherwise we call deduceLocale()
>> and use what it returns. A bit twisted in that an overridden
>> deduceLocale() could do all this alone (examine servletRequest.locale,
>> decide if it will override it), but I guess this is the most practical
>> compromise.
>
> OK. Sounds great! Thanks for clarification! I'll try to create a PR
> for this soon.
>
>>
>> Note that for any of these init-params, even where right now we only
>> have two possible values, I prefer a string value over a boolean
>> because it's more future proof.
>
> Makes sense.
>
> Thanks a lot!
>
> Cheers,
>
> Woonsan
>
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>>> Regards,
>>>
>>> Woonsan
>>>
>>>
>>> On Mon, Oct 19, 2015 at 4:28 AM, Daniel Dekany wrote:
>>>> So I have merged this
>>>> (https://issues.apache.org/jira/browse/FREEMARKER-1) in, but while
>>>> reviewing the stuff, I have realized that I'm not sure how exactly
>>>> this should work, especially as OutputFormat-s (the main 2.3.24
>>>> feature, mostly used for auto-escaping, but usually also specifies a
>>>> MIME type) comes into the picture. As far as I see, the most generic
>>>> solution would be this:
>>>>
>>>> The new "OverrideResponseContentType" FreemarkerServlet init-param
>>>> (the topic of https://issues.apache.org/jira/browse/FREEMARKER-1)
>>>> could have three values:
>>>>
>>>
Re: Abandoning Servlet 2.3 support?
Eh... do you know how perversely conservative FM is? :) It's the coming FreeMarker 2.3.24 that will raise the minimum Java version from 1.4 to 5. Before that, 2.3.23, which was about 6 months ago, has raised it from 1.2(!) to 1.4. (Just so we don't look crazy... why Java 5? There was nothing critical for us in 6 yet (OK, number rounding modes, but I just call that via some conditional linking). Also Spring 3.x requires Java 5, hence if we want 2.3.24 to be part of a 3.x maintenance release, it can't require any higher.) Sunday, October 25, 2015, 5:23:31 PM, Ralph Goers wrote: > Frankly, I would have dropped support for servlet 2.3 a while ago. > Same for Java 5. Heck Log4j just made the minimum version Java 7. > > Ralph > >> On Oct 21, 2015, at 11:58 AM, Daniel Dekany wrote: >> >> We will need to call some Servlet 2.4 API-s, and I can solve it >> reflection and such, and by complication the build.xml a bit further. >> I just wonder if it worths it. Here's a bit of Servlet history: >> >> Servlet 2.3 August 2001 J2EE 1.3, J2SE 1.2 JSP 1.2 >> Servlet 2.4 November 2003 J2EE 1.4, J2SE 1.3 JSP 2.0 >> Servlet 2.5 September 2005 JavaEE 5, JavaSE 5 JSP 2.1 >> >> 2.3.24 has already raised minimum Java version to 5, and minimum JSP >> version to 2.0 (that's the pair of Servlet 2.4). These had to be done, >> pretty much. Requiring 2.4 is not a must have, but I wonder if keeping >> it worths the complication... >> >> -- >> Thanks, >> Daniel Dekany >> >> > > > -- Thanks, Daniel Dekany
Re: FREEMARKER-4 - Some one completed this ?
I have updated the site. (Until the currently ongoing domain transfer is finished, updating the actual Web site is not possible via SVN commit, so right now I'm the only one who can do it... I hope the situation will improve soon.) BTW, I have noticed an (old) issue with Docgen and CSS updates. As it refers to the CSS like: the CSS won't be necessary updated together with the HTML at the visitors. This can be a problem when both has to be changed on sync. This typical issue could be fixed if we continue that URL with something like "?hash=AC50CFED045B0894004A". You see the trick... the query parameter, which is calculated from the hash of docgen.min.css will force the browser to reload it, rather than using a cached CSS. -- Thanks, Daniel Dekany Monday, October 26, 2015, 6:50:37 PM, Evangelia Dendramis wrote: > Yes, I fixed it. The website just needs to be built > > On Mon, Oct 26, 2015 at 7:12 AM, Pradeep Murugesan < > pradeepmuruge...@outlook.com> wrote: > >> >> Sounds like a quick fix [image: �] so thought of taking it up [image: �] >> >> >> Pradeep. >>
Re: Adding a new BuiltIn - previousSibling
OK, let's see. I have ran through the diff and have spotted these
(just in the order as I find then):
putBI("previousSibling", new previousSiblingBI()), etc. should be
putBI("previous_sibling", "previousSibling", new previousSiblingBI()).
BuiltInExtForNode: Doesn't follow the naming pattern of the other
BuiltIns... classes.
TemplateNodeModelExt: Should be TemplateNodeModelEx (as we already
have other Ex models, we are stuck with that convention...)
BuiltinVariable: You have registered two new names there, but these
aren't built-in variables.
In ElementModel: @@previous and @@next doesn't yet implement what we
were talking about. I mean, it doesn't just skip white-space and
comments and PI-s, but any text nodes. (Also an XPath-based
implementation won't be very fast. org.w3c.dom.Node-s has
getPreviousSibling()/getNextSibling() methods. Also, if you will skip
WS text only, you won't be able to do that with XPath anyway.)
(As a policy, there should not be author comments ("created by") in
the source code.)
--
Thanks,
Daniel Dekany
Friday, October 23, 2015, 9:09:56 PM, Pradeep Murugesan wrote:
> Hi Daniel,
>
> https://github.com/pradeepmurugesan/incubator-freemarker/commit/465ed1bd768e8a5bee91bea7d3b291a5872efae5
> I have added the builtIns which will return blindly the previous
> and next sibling and also the special variables @@previous and
> @@next which will return the valid node. In the special variable
> case I have used the xpath to get the required nodes.
> Kindly review and let me know your thoughts.
> Pradeep.
>> Date: Sun, 18 Oct 2015 11:42:04 +0200
>> From: ddek...@freemail.hu
>> To: dev@freemarker.incubator.apache.org
>> Subject: Re: Adding a new BuiltIn - previousSibling
>>
>> Returning the sibling node without skipping stuff is not XML-specific,
>> so certainly that should be ?previous (and a new method in the new
>> TemplateNodeModelEx interface), not a hash key that starts with "@".
>>
>> BTW, of course all of these has an opposite direction variant, like
>> "@next". And "@prev" may should be "@previous".
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>>
>> Sunday, October 18, 2015, 5:31:50 AM, Pradeep Murugesan wrote:
>>
>> > yeah makes sense..
>> > so we need to return a valid element node he is looking for
>> > skipping all the whitespace, CDATA etc...
>> > I am wondering if the user will have any reason to look for a CDATA
>> > sibling or any non element sibling which we will skip.
>> > In that case can we have 2 special cases.
>> > 1. @prev which will return the immediate sibling2. @prevNode or
>> > something intutive which will return a valid element skipping few .
>> > Pradeep.
>> >> Date: Sat, 17 Oct 2015 20:15:57 +0200
>> >> From: ddek...@freemail.hu
>> >> To: dev@freemarker.incubator.apache.org
>> >> Subject: Re: Adding a new BuiltIn - previousSibling
>> >>
>> >> Saturday, October 17, 2015, 7:09:49 PM, Pradeep Murugesan wrote:
>> >>
>> >> > hmm then I think @@prev should return the immediate sibling with the
>> >> > following issues/advantages.
>> >> > 1. In xml doc its a overhead for user to call it twice to get the
>> >> > previous element node2.
>> >>
>> >> It much worse than that, if it just returns the previous sibling on
>> >> the DOM, as you can't know if you have to call it once, twice, 3
>> >> times, etc.
>> >>
>> >> > For less document centric it is not a problem.
>> >>
>> >> For non-document XML it's similarly desirable. I meant JSON and such,
>> >> where @@prev doesn't exist anyway...
>> >>
>> >> > 3. for Non-normalized dom we wont do anything before they normalize it .
>> >>
>> >> Actually, we can do a little effort... skipping *all* the
>> >> white-space-only character date nodes and comments and PI-s. But
>> >> that's all.
>> >>
>> >> > Let me know If I got that correctly.
>> >> > If so I will add @@prev as a special case and use
>> >> > .node.@@prev.@@prev to get to theprevious sibling node.
>> >>
>> >> You mean, you will use: .node.@@prev
>> >>
>> >> > Pradeep.
>> >> >
>> >> >> Date: Fri, 16 Oct 2015 01:09:36 +0200
>> >> >> From: ddek...@freemail.hu
>> >> >> To: dev@freemarker.incubator.apache
Re: Adding a new BuiltIn - previousSibling
Monday, October 26, 2015, 3:01:56 PM, Pradeep Murugesan wrote:
> HI Daniel,
>
> You got a chance to review this ?
Sorry, I haven't forgotten it, really, it's just that I'm "bit"
overburden... See other mail.
I have forgotten to mention there, but of course eventually we need
JUnit tests too.
> I have now added a datamodel for the template in the page
> "incubator-freemarker/build/manual/dgui_quickstart_template.html".
> Template block containing the sentence "Welcome ${user}<#if user ==
> "Big Joe">, our beloved leader!".
>
> I have pushed the code both
> freemarker(https://github.com/pradeepmurugesan/incubator-freemarker/)
> and
> freemarker-docgen(https://github.com/pradeepmurugesan/incubator-freemarker-docgen).
Um... I don't see your commits there.
> When you find time Kindly check and let me know if we can proceed?
>
> Pradeep.
>
>
>
>
> From: Pradeep Murugesan
> Sent: Saturday, October 24, 2015 1:39 AM
> To: dev@freemarker.incubator.apache.org
> Subject: RE: Adding a new BuiltIn - previousSibling
>
> Hi Daniel,
>
> https://github.com/pradeepmurugesan/incubator-freemarker/commit/465ed1bd768e8a5bee91bea7d3b291a5872efae5
> I have added the builtIns which will return blindly the previous
> and next sibling and also the special variables @@previous and
> @@next which will return the valid node. In the special variable
> case I have used the xpath to get the required nodes.
> Kindly review and let me know your thoughts.
> Pradeep.
>> Date: Sun, 18 Oct 2015 11:42:04 +0200
>> From: ddek...@freemail.hu
>> To: dev@freemarker.incubator.apache.org
>> Subject: Re: Adding a new BuiltIn - previousSibling
>>
>> Returning the sibling node without skipping stuff is not XML-specific,
>> so certainly that should be ?previous (and a new method in the new
>> TemplateNodeModelEx interface), not a hash key that starts with "@".
>>
>> BTW, of course all of these has an opposite direction variant, like
>> "@next". And "@prev" may should be "@previous".
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>>
>> Sunday, October 18, 2015, 5:31:50 AM, Pradeep Murugesan wrote:
>>
>> > yeah makes sense..
>> > so we need to return a valid element node he is looking for
>> > skipping all the whitespace, CDATA etc...
>> > I am wondering if the user will have any reason to look for a CDATA
>> > sibling or any non element sibling which we will skip.
>> > In that case can we have 2 special cases.
>> > 1. @prev which will return the immediate sibling2. @prevNode or
>> > something intutive which will return a valid element skipping few .
>> > Pradeep.
>> >> Date: Sat, 17 Oct 2015 20:15:57 +0200
>> >> From: ddek...@freemail.hu
>> >> To: dev@freemarker.incubator.apache.org
>> >> Subject: Re: Adding a new BuiltIn - previousSibling
>> >>
>> >> Saturday, October 17, 2015, 7:09:49 PM, Pradeep Murugesan wrote:
>> >>
>> >> > hmm then I think @@prev should return the immediate sibling with the
>> >> > following issues/advantages.
>> >> > 1. In xml doc its a overhead for user to call it twice to get the
>> >> > previous element node2.
>> >>
>> >> It much worse than that, if it just returns the previous sibling on
>> >> the DOM, as you can't know if you have to call it once, twice, 3
>> >> times, etc.
>> >>
>> >> > For less document centric it is not a problem.
>> >>
>> >> For non-document XML it's similarly desirable. I meant JSON and such,
>> >> where @@prev doesn't exist anyway...
>> >>
>> >> > 3. for Non-normalized dom we wont do anything before they normalize it .
>> >>
>> >> Actually, we can do a little effort... skipping *all* the
>> >> white-space-only character date nodes and comments and PI-s. But
>> >> that's all.
>> >>
>> >> > Let me know If I got that correctly.
>> >> > If so I will add @@prev as a special case and use
>> >> > .node.@@prev.@@prev to get to theprevious sibling node.
>> >>
>> >> You mean, you will use: .node.@@prev
>> >>
>> >> > Pradeep.
>> >> >
>> >> >> Date: Fri, 16 Oct 2015 01:09:36 +0200
>> >> >> From: ddek...@freemail.hu
>> >> >> To: dev@freemarker.incubator.apa
Re: Adding a new BuiltIn - previousSibling
Tuesday, October 27, 2015, 6:04:19 PM, Pradeep Murugesan wrote:
> Hi Daniel,
>
> Have fixed the code review comments here.
> https://github.com/pradeepmurugesan/incubator-freemarker/commit/2e1b0d834e941eaf4ea8aafad720333c7ec1040c
It's minor issue, but BuiltInsExtForNode and BuiltInExtForNod still
don't follow the same convention as the others. The ...BI classes
should just be inside BuiltInsForNodes (no need for
BuiltInsExtForNode), and BuiltInExtForNode should be called
BuiltInForNodeEx.
> Regarding the @@previous and @@next we decided to skip the
> whitespaces and other character data. Instead I tried to find first
> occurrence of the node which is of type Node.ELEMENT_NODE
By that do you mean that you intend to continue it later so that it
will only skip whitespace, etc., or you think this approach is more
practical? (If it's the later, why?)
Also, I believe that the current implementation will throw
NullPointerException after you have reached the first or the last
node.
> https://github.com/pradeepmurugesan/incubator-freemarker/commit/2e1b0d834e941eaf4ea8aafad720333c7ec1040c#diff-a029bb56a7cedf8c6272a6d8b566f446
>
> I tried few cases and things worked fine there. Kindly let me know your
> thoughts.
>
> P.S : I am working on the Junit test cases.
>
> Pradeep.
>
>
> From: Daniel Dekany
> Sent: Tuesday, October 27, 2015 3:36 AM
> To: Pradeep Murugesan
> Subject: Re: Adding a new BuiltIn - previousSibling
>
> OK, let's see. I have ran through the diff and have spotted these
> (just in the order as I find then):
>
> putBI("previousSibling", new previousSiblingBI()), etc. should be
> putBI("previous_sibling", "previousSibling", new previousSiblingBI()).
>
> BuiltInExtForNode: Doesn't follow the naming pattern of the other
> BuiltIns... classes.
>
> TemplateNodeModelExt: Should be TemplateNodeModelEx (as we already
> have other Ex models, we are stuck with that convention...)
>
> BuiltinVariable: You have registered two new names there, but these
> aren't built-in variables.
>
> In ElementModel: @@previous and @@next doesn't yet implement what we
> were talking about. I mean, it doesn't just skip white-space and
> comments and PI-s, but any text nodes. (Also an XPath-based
> implementation won't be very fast. org.w3c.dom.Node-s has
> getPreviousSibling()/getNextSibling() methods. Also, if you will skip
> WS text only, you won't be able to do that with XPath anyway.)
>
> (As a policy, there should not be author comments ("created by") in
> the source code.)
>
> --
> Thanks,
> Daniel Dekany
>
>
> Friday, October 23, 2015, 9:09:56 PM, Pradeep Murugesan wrote:
>
>> Hi Daniel,
>>
>> https://github.com/pradeepmurugesan/incubator-freemarker/commit/465ed1bd768e8a5bee91bea7d3b291a5872efae5
>> I have added the builtIns which will return blindly the previous
>> and next sibling and also the special variables @@previous and
>> @@next which will return the valid node. In the special variable
>> case I have used the xpath to get the required nodes.
>> Kindly review and let me know your thoughts.
>> Pradeep.
>>> Date: Sun, 18 Oct 2015 11:42:04 +0200
>>> From: ddek...@freemail.hu
>>> To: dev@freemarker.incubator.apache.org
>>> Subject: Re: Adding a new BuiltIn - previousSibling
>>>
>>> Returning the sibling node without skipping stuff is not XML-specific,
>>> so certainly that should be ?previous (and a new method in the new
>>> TemplateNodeModelEx interface), not a hash key that starts with "@".
>>>
>>> BTW, of course all of these has an opposite direction variant, like
>>> "@next". And "@prev" may should be "@previous".
>>>
>>> --
>>> Thanks,
>>> Daniel Dekany
>>>
>>>
>>> Sunday, October 18, 2015, 5:31:50 AM, Pradeep Murugesan wrote:
>>>
>>> > yeah makes sense..
>>> > so we need to return a valid element node he is looking for
>>> > skipping all the whitespace, CDATA etc...
>>> > I am wondering if the user will have any reason to look for a CDATA
>>> > sibling or any non element sibling which we will skip.
>>> > In that case can we have 2 special cases.
>>> > 1. @prev which will return the immediate sibling2. @prevNode or
>>> > something intutive which will return a valid element skipping few .
>>> > Pradeep.
>>> >> Date: Sat, 17 Oct 2015 20:15:57 +0200
>>> >> From: ddek...@freemail.hu
>>> >> To: dev@freemar
Re: Adding a new BuiltIn - previousSibling
Wednesday, October 28, 2015, 3:52:35 AM, Pradeep Murugesan wrote:
>> By that do you mean that you intend to continue it later so that it
>> will only skip whitespace, etc., or you think this approach is more
>> practical? (If it's the later, why?)
>
> So by @@previous the user expects the previous node. But
> currently it returns the \n , spaces, as you mentioned CDATA etc.
> To skip these we need to maintain a list of blacklisted candidates
> to skip. Today we have 3 candidates (let's assume) later we may get
> lot to skip which we should be adding as blacklisted.
> I went for this approach assuming there won't be any scenario
> where we skip any nodes of type ELEMENT_NODE to fetch the
> previousSibling node. If we will skip ELEMENT_NODE as well then no
> other go we need to maintain a list of candidates to skip.
I'm not sure what you mean be "maintaining". We just check the node on
the fly, and decide if we proceed with its sibling or return it. What
we want to skip certainly won't change over time, as the information
model of XML won't change any time soon, if ever. It's WS-only text
(it doesn't mater if it's plain text or a CDATA section), comments and
PI-s. (We never skip elements.)
> Kindly let me know if I am wrong.
>
> Regarding the nullPointer exception I have handled it. But Didn't
> commit. Its like parent directive right we will return null if its
> the root node, similarly we can return null if its first and last
> accessing previous and next respectively.
>
> Pradeep.
>
> From: Daniel Dekany
> Sent: Wednesday, October 28, 2015 2:45 AM
> To: Pradeep Murugesan
> Subject: Re: Adding a new BuiltIn - previousSibling
>
> Tuesday, October 27, 2015, 6:04:19 PM, Pradeep Murugesan wrote:
>
>> Hi Daniel,
>>
>> Have fixed the code review comments here.
>> https://github.com/pradeepmurugesan/incubator-freemarker/commit/2e1b0d834e941eaf4ea8aafad720333c7ec1040c
>
> It's minor issue, but BuiltInsExtForNode and BuiltInExtForNod still
> don't follow the same convention as the others. The ...BI classes
> should just be inside BuiltInsForNodes (no need for
> BuiltInsExtForNode), and BuiltInExtForNode should be called
> BuiltInForNodeEx.
>
>> Regarding the @@previous and @@next we decided to skip the
>> whitespaces and other character data. Instead I tried to find first
>> occurrence of the node which is of type Node.ELEMENT_NODE
>
> By that do you mean that you intend to continue it later so that it
> will only skip whitespace, etc., or you think this approach is more
> practical? (If it's the later, why?)
>
> Also, I believe that the current implementation will throw
> NullPointerException after you have reached the first or the last
> node.
>
>> https://github.com/pradeepmurugesan/incubator-freemarker/commit/2e1b0d834e941eaf4ea8aafad720333c7ec1040c#diff-a029bb56a7cedf8c6272a6d8b566f446
>>
>> I tried few cases and things worked fine there. Kindly let me know your
>> thoughts.
>>
>> P.S : I am working on the Junit test cases.
>>
>> Pradeep.
>>
>>
>> From: Daniel Dekany
>> Sent: Tuesday, October 27, 2015 3:36 AM
>> To: Pradeep Murugesan
>> Subject: Re: Adding a new BuiltIn - previousSibling
>>
>> OK, let's see. I have ran through the diff and have spotted these
>> (just in the order as I find then):
>>
>> putBI("previousSibling", new previousSiblingBI()), etc. should be
>> putBI("previous_sibling", "previousSibling", new previousSiblingBI()).
>>
>> BuiltInExtForNode: Doesn't follow the naming pattern of the other
>> BuiltIns... classes.
>>
>> TemplateNodeModelExt: Should be TemplateNodeModelEx (as we already
>> have other Ex models, we are stuck with that convention...)
>>
>> BuiltinVariable: You have registered two new names there, but these
>> aren't built-in variables.
>>
>> In ElementModel: @@previous and @@next doesn't yet implement what we
>> were talking about. I mean, it doesn't just skip white-space and
>> comments and PI-s, but any text nodes. (Also an XPath-based
>> implementation won't be very fast. org.w3c.dom.Node-s has
>> getPreviousSibling()/getNextSibling() methods. Also, if you will skip
>> WS text only, you won't be able to do that with XPath anyway.)
>>
>> (As a policy, there should not be author comments ("created by") in
>> the source code.)
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>>
&g
Re: Adding a new BuiltIn - previousSibling
Wednesday, October 28, 2015, 6:21:19 PM, Pradeep Murugesan wrote: > Hi Daniel, > > I agree with that but I have a question kindly don't take it as an argument. > Just curious to know > > 1. cdata > 2.\n > 3. comments > 4. some PI's > > In all the above 4 scenarios when we do a @@previous on node 'b' we expect > node 'a'. With what you have implemented so far, that is. > I am suggesting we will keep iterating until we find a node type > ELEMENT_NODE and return it. > you are suggesting to keep iterating until we find a node that is not in \n, > CDATA, PIs etc. > > I think both will work. Do you think any of it which should be > skipped will also have node type ELEMENT_NODE. Nope. > I am not sure about what is a better logic though. Kindly let me > know if I am not getting something which you are telling. Silently skipping non-whitespace text is dangerous. But if you call this @@previous_element, then the user will expect it to happen, so then what you have implemented can be OK. As of my @@previous definition, the name is problematic even there, as it doesn't just return the previous sibling (?previousSibling does that). It does some magic, by skipping whitespace and such. So certainly it should be called @@prevous_significant or @@previous_non_ws, so that it's clear that some trickery is involved. As of the semantic, the motivation is simply to return what many naturally expect to be the previous node. Like remember your case; getting some text instead of the preceding programlisting element was unexpected at first, I assume. Yes, your definition of @@previous fixes that too. But if you had some non-whitespace text between those two programlisting elements, certainly you expect to get that text, not the element before it. People don't see non-whitespace text as ignorable, because in fact it hardly ever is. So after renaming both operations are OK, but I think @@previous_significant is a safer operation than @@previous_element, because you won't unintentionally skip non-whitespace text with it. Surely @@previous_element is quite clear about what it does (that it will skip text), but then, what can the users do about it? They will have to hope that there won't be any non-whitespace text before the target element, ever. Because when there is, they won't know about it, they can't give an error or something. With @@prevous_significant, when that assumption fails, they will get the text node and the template that expects an element can fail or take some special action, so there's no silent information loss. -- Thanks, Daniel Dekany > Pradeep. > > From: Daniel Dekany > Sent: Wednesday, October 28, 2015 1:33 PM > To: Pradeep Murugesan > Subject: Re: Adding a new BuiltIn - previousSibling > > Wednesday, October 28, 2015, 3:52:35 AM, Pradeep Murugesan wrote: > >>> By that do you mean that you intend to continue it later so that it >>> will only skip whitespace, etc., or you think this approach is more >>> practical? (If it's the later, why?) >> >> So by @@previous the user expects the previous node. But >> currently it returns the \n , spaces, as you mentioned CDATA etc. >> To skip these we need to maintain a list of blacklisted candidates >> to skip. Today we have 3 candidates (let's assume) later we may get >> lot to skip which we should be adding as blacklisted. >> I went for this approach assuming there won't be any scenario >> where we skip any nodes of type ELEMENT_NODE to fetch the >> previousSibling node. If we will skip ELEMENT_NODE as well then no >> other go we need to maintain a list of candidates to skip. > > I'm not sure what you mean be "maintaining". We just check the node on > the fly, and decide if we proceed with its sibling or return it. What > we want to skip certainly won't change over time, as the information > model of XML won't change any time soon, if ever. It's WS-only text > (it doesn't mater if it's plain text or a CDATA section), comments and > PI-s. (We never skip elements.) > >> Kindly let me know if I am wrong. >> >> Regarding the nullPointer exception I have handled it. But Didn't >> commit. Its like parent directive right we will return null if its >> the root node, similarly we can return null if its first and last >> accessing previous and next respectively. >> >> Pradeep. >> >> From: Daniel Dekany >> Sent: Wednesday, October 28, 2015 2:45 AM >> To: Pradeep Murugesan >> Subject: Re: Adding a new BuiltIn - previousSibling >> >> Tuesday, October 2
Re: IRC for freemarker
Heh... I didn't know about this. It says "FreeMarker - Java Template Library - http://freemarker.org/ - Latest is 2.3.15 - 16 december 2008". A bit dated, but hey... :) Thursday, October 29, 2015, 10:02:04 AM, Jacques Le Roux wrote: > This worked for me https://webchat.freenode.net/# (freemarker > channel, I used my Apache username but I guess any works) > > Jacques > > Le 29/10/2015 03:16, Pradeep Murugesan a écrit : >> Team, >> >> >> do we have any irc channel for freemarker ? >> >> >> Pradeep. >> > -- Thanks, Daniel Dekany
Re: Question on unit testing
It would be in fact very good news if this thing can go with Maven... looking forward for the results! Thursday, October 29, 2015, 10:54:50 AM, Woonsan Ko wrote: >>> By the way, IIRC, you mentioned in old ML that it's planned to migrate >>> to Maven some day. Is it right? If so, when do you want to do that? >> >> I'm not sure if that would work out well, given that FM needs to be >> compiled against multiple versions of the same library (including >> rt.jar). But if someone works this topic out, it might turns out that >> it's feasible after all. I don't know. But the bet is on Gradle. And >> that will probably only happen when someone other than me takes that >> task. > > I think it should be possible with Maven (e.g, by using multiple > activatable profiles and system dependencies). I'd like to experiment > it in a branch. Will let you know if I make some progress. :-) > > Cheers, > > Woonsan > -- Thanks, Daniel Dekany
Re: freemarker.org is down.
I have reported this DNS problem to infra about 3 days ago, and they basically said that they haven't finished the domain transfer issue (INFRA-10604) yet. I have commended on INFRA-10604 now, just in case they have forgotten about this semi-finished transfer somehow. -- Thanks, Daniel Dekany Monday, November 2, 2015, 5:26:09 PM, Stephan Müller wrote: > Am 02.11.2015 um 17:09 schrieb Pete Helgren: >> I recently completed the transfer of the freemarker.org domain (which I >> owned) over to the Apache Software Foundation to meet the requirements >> of being an incubator project. So my guess is that the DNS entries for >> the site haven't been set up or configured at ASF. That is about as much >> as I know: I was requested to transfer the domain and the domain was >> transferred. > > Yep, it's a DSN issue, see > https://issues.apache.org/jira/browse/FREEMARKER-6. The actual web > server is up and running, but DNS requests for freemarker.org run into a > timeout. > > > > Stephan Müller. > > >> Pete Helgren >> www.petesworkshop.com >> GIAC Secure Software Programmer-Java >> >> >> On 11/2/2015 7:31 AM, Pradeep Murugesan wrote: >>> Do we have any deployments going on ? >>> >>> >>> Or Am I the only person facing this ? >>> >>> >>> Pradeep. >>> >> >> > >
Re: Free marker contribution
Until ASF infra solves this DNS issue, here's a copy of the relevant pages: http://freemarker.incubator.apache.org/contribute.html http://freemarker.incubator.apache.org/sourcecode.html The full documentation can be found in the distribution, which you can get at http://sourceforge.net/projects/freemarker/ Bug fixing.. you can hunt around on http://sourceforge.net/p/freemarker/bugs/, though most of the bugs is still there because there's some deeper problem with solving them. Only very few is there because nobody has looked into them, like for example, this: http://sourceforge.net/p/freemarker/bugs/434/, also there were something about the XML transformer Ant task. Monday, November 2, 2015, 12:50:31 PM, priya gachinamath wrote: > Hello Daniel, > > Thanks for the response. Yes, the link does not work as you mentioned in > your email. But I can get started with contributing to the project by > fixing a few bugs before I pick up some feature to implement which I would > eventually like to do. So, please assign me a bug to fix. > > Thanks and regards, > Priya -- Thanks, Daniel Dekany
Re: Free marker contribution
Also this bug, since we have switched to Java 5 now, before 2.4.0: http://sourceforge.net/p/freemarker/bugs/422/ Monday, November 2, 2015, 8:19:00 PM, Daniel Dekany wrote: > Until ASF infra solves this DNS issue, here's a copy of the relevant > pages: > http://freemarker.incubator.apache.org/contribute.html > http://freemarker.incubator.apache.org/sourcecode.html > > The full documentation can be found in the distribution, which you can > get at http://sourceforge.net/projects/freemarker/ > > Bug fixing.. you can hunt around on > http://sourceforge.net/p/freemarker/bugs/, though most of the bugs is > still there because there's some deeper problem with solving them. > Only very few is there because nobody has looked into them, like for > example, this: http://sourceforge.net/p/freemarker/bugs/434/, also > there were something about the XML transformer Ant task. > > > Monday, November 2, 2015, 12:50:31 PM, priya gachinamath wrote: > >> Hello Daniel, >> >> Thanks for the response. Yes, the link does not work as you mentioned in >> your email. But I can get started with contributing to the project by >> fixing a few bugs before I pick up some feature to implement which I would >> eventually like to do. So, please assign me a bug to fix. >> >> Thanks and regards, >> Priya > -- Thanks, Daniel Dekany
Should freemarker.org remain the canonical domain?
Infra has managed to set up the DNS (but some other issue has popped up, so now I suddenly can't update the site content, so we are still screwed... a different mater anyway). But to my surprise, they redirect http://freemarker.org to http://freemarker.incubator.apache.org/ (via HTTP 301, temporal redirection). When I asked infra about this (https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-10604), they said that it's how it normally goes, and I should speak to tradema...@apache.org if I want to keep freemarker.org as the canonical URL. So, should I ask them? I believe that's the project's interest, so personally, I'm in favor of keeping freemarker.org as the canonical project domain, until we graduate from incubation. What do you think? -- Thanks, Daniel Dekany
Re: Should freemarker.org remain the canonical domain?
Guys, you both misunderstand the question in the same way for some reason. freemarker.org already redirects to freemarker.incubator.apache.org. That's exactly my problem. I expected to only have freemarker.org (or freemarker.incubator.apache.org to redirect to freemarker.org) behind which the content is served by an ASF server, until we graduate. For that, I have to ask tradema...@apache.org, and I'm asking you, if I should ask them, or you prefer the current situation (i.e., having freemarker.incubator.apache.org as the canonical URL). I haven't intended to change our 10+ year old and nice concise domain name for now, I have merely asked for the domain ownership to change. So I was surprised by this development. -- Thanks, Daniel Dekany Thursday, November 5, 2015, 6:11:35 AM, Jacopo Cappellato wrote: > I think that the project should keep it, and it should redirect to the > actual domain: > freemarker.org -->> freemarker.incubator.apache.org (now) freemarker.org -->> freemarker.apache.org (after graduation) > > We did something similar with OFBiz and its ofbiz.org domain. > > Jacopo > > > On Tue, Nov 3, 2015 at 11:57 PM, Daniel Dekany wrote: > >> Infra has managed to set up the DNS (but some other issue has popped >> up, so now I suddenly can't update the site content, so we are still >> screwed... a different mater anyway). But to my surprise, they >> redirect http://freemarker.org to >> http://freemarker.incubator.apache.org/ (via HTTP 301, temporal >> redirection). When I asked infra about this >> (https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-10604 >> ), >> they said that it's how it normally goes, and I should speak to >> tradema...@apache.org if I want to keep freemarker.org as the >> canonical URL. >> >> So, should I ask them? I believe that's the project's interest, so >> personally, I'm in favor of keeping freemarker.org as the canonical >> project domain, until we graduate from incubation. What do you think? >> >> -- >> Thanks, >> Daniel Dekany >> >>
Re: Adding a new BuiltIn - previousSibling
Tuesday, November 3, 2015, 7:19:17 AM, Pradeep Murugesan wrote:
> Hi Daniel,
>
> I have made the changes you have said and writing unit tests. I
> have written an unit test and need to check whether can I proceed in
> the same fashion. One important question I have is accessing the
> (XML) datamodel required for the testcase.
>
> Now I am overriding the function getDataModel() and read the xml
> from a file. Kindly let me know if that is acceptable.
You don't need to override getDateModel(). Just add "doc" to the data
model with the TemplateTest.addToDataModel.
Loading the XML file via java.io.File API is not entirely correct,
especially not with that relative path ("build/test-classes/..."). You
don't know what the current directory will be on the CI server for
example. Also, though an extreme case, but it can also occur that a
test suite is ran from an unexploded jar (i.e., you don't even have
real files anywhere). Just like outside tests, the correct solution is
using Class.getResource or Class.getResourceAsStream to read
class-loader resources.
Also I guess inside the testPreviousSibling you don't really need
output capturing, nor ?trim.
> https://github.com/pradeepmurugesan/incubator-freemarker/commit/42132df19b6f8e53f66ff3f6cbbce459376c65a6
>
>
> P.S : I have removed the author name in next commit. Intellij adds
> it and I am missing it everytime. Sorry!!.
>
> Pradeep.
>
>
>
>
> From: Pradeep Murugesan
> Sent: Thursday, October 29, 2015 7:46 AM
> To: dev@freemarker.incubator.apache.org
> Subject: Re: Adding a new BuiltIn - previousSibling
>
> oh now I got it.
>
> So we can also expect something like
> there is some text here
>
> Now when the user do a @@previous on node 'b' he will get node 'a'
> but he might expect "there is some text here" which is still a valid text
> node.
>
> I thought there can be no such scenario so kept hanging on with
> blindly skipping all till we get a node. So I will do the following .
>
> 1. rename to @@previous_significant
> 2. skip the siblings when its in any of the blacklisted candidates.
> ( whitespaces, CDATA, \n(ofcourse))
>
> Pradeep.
>
>
> From: Daniel Dekany
> Sent: Thursday, October 29, 2015 4:12 AM
> To: Pradeep Murugesan
> Subject: Re: Adding a new BuiltIn - previousSibling
>
> Wednesday, October 28, 2015, 6:21:19 PM, Pradeep Murugesan wrote:
>
>> Hi Daniel,
>>
>> I agree with that but I have a question kindly don't take it as an
>> argument. Just curious to know
>>
>> 1. cdata
>> 2.\n
>> 3. comments
>> 4. some PI's
>>
>> In all the above 4 scenarios when we do a @@previous on node 'b' we expect
>> node 'a'.
>
> With what you have implemented so far, that is.
>
>> I am suggesting we will keep iterating until we find a node type
>> ELEMENT_NODE and return it.
>> you are suggesting to keep iterating until we find a node that is not in \n,
>> CDATA, PIs etc.
>>
>> I think both will work. Do you think any of it which should be
>> skipped will also have node type ELEMENT_NODE.
>
> Nope.
>
>> I am not sure about what is a better logic though. Kindly let me
>> know if I am not getting something which you are telling.
>
> Silently skipping non-whitespace text is dangerous. But if you call
> this @@previous_element, then the user will expect it to happen, so
> then what you have implemented can be OK.
>
> As of my @@previous definition, the name is problematic even there, as
> it doesn't just return the previous sibling (?previousSibling does
> that). It does some magic, by skipping whitespace and such. So
> certainly it should be called @@prevous_significant or
> @@previous_non_ws, so that it's clear that some trickery is involved.
> As of the semantic, the motivation is simply to return what many
> naturally expect to be the previous node. Like remember your case;
> getting some text instead of the preceding programlisting element was
> unexpected at first, I assume. Yes, your definition of @@previous
> fixes that too. But if you had some non-whitespace text between those
> two programlisting elements, certainly you expect to get that text,
> not the element before it. People don't see non-whitespace text as
> ignorable, because in fact it hardly ever is.
>
> So after renaming both operations are OK, but I think
> @@previous_significant is a safer operation than @@previous_element,
> because you won't unintentionally skip non-whitespace text with it.
> Surely @@previous_element i
Re: Maven build (WAS: Fwd: Question on unit testing)
Tuesday, November 3, 2015, 8:31:41 AM, Woonsan Ko wrote: > Hi, > > I've just made an initial experiment PR to use Maven instead: > - https://github.com/apache/incubator-freemarker/pull/8 > > Build works well mostly and seems to create an artifact properly > (target/freemarker-2.3.24-SNAPSHOT.jar). > > However, as described in the PR, there are some issues and things to note: > - Two unit tests fail: RealServletContainertTest#basicTrivial() and > RealServletContainertTest#basicELFunctions(). > This seems related to war initialization issue. For example, the > existing ant build copies all the necessary jar files into WEB-INF/lib > somehow, but the new maven doesn't have that. I haven't looked into this (yet), but there's no Ant magic involved. After all the JUnit tests run successfully be merely right clicking on the project in Eclipse, then choosing Run as JUnit Test. > - To support incompatible multiple versions of jython, I decided to > use the latest version of jython only and use Reflection APIs for the > older versions of jython in two classes because those two classes are > very small/simple and seems more effective using Reflection APIs. I'm worried about runtime efficiency there, at least when it comes to getPythonClassName. Reflection is relatively slow, especially a lot of it. > - Similarly, I simply added a new jsp-api 2.1 operation in a base > class to support both 2.0 and 2.1 at runtime. I think this approach > should be simpler than complex dependency management and multiple > compilations. You are still linking to JSP 2.1 classes there (JspApplicationContext and ELContext as the declared return value), even if you are just throwing UnsupportedOperationException there instead of returning an instance. And so it will still fail on runtime, unless I miss something. > Regarding RealServletContainertTest and testing with embedded jetty > server, one of natural solutions in Maven is to organize the project > into multiple modules. > For example, maybe we can change the project structure into this: > > - freemarker > |- core > `- test > `- web > > If test/web is a 'war' package project, then we don't have to copy > jars into WEB-INF/lib manually, but we can probably take advantage of > the existing features of jetty plugin or other (e.g, cargo) for > packaging in (integration)test phase, for instance. Right now I hope that we actually don't do any such hack with Ant either, and so there won't be Maven work around either. (See earlier.) > Also, the Reflection API usages for those two test classes seem okay > enough to me, but if there's any strong reason to validate those as > early as possible, then maybe we can add more submodules for each > specific purpose. I don't see reflection in *test* classes in the pull request. You meant the non-test classes? > Anyway, I'd like to share my initial experiment with you folks and > hear from you about approaches. > If we need to restructure the modules, then it should be better to get > a consensus in prior anyway. So, the reason I though Maven won't cut it is exactly the problem with linking to multiple dependency versions. Right now the number of such cases is quite low, compared to most earlier FreeMarker versions, but I don't know how that will change in the future. Anyway, I would accept any solution where it's just awkward to do these, but using a solution that substantially affects the actual output (i.e., has runtime impact), all because of the build tool, well... it's hard to accept for me. OTOH I do want Maven, and ready to accept all kind of horrid hacks as far as they won't affect the runtime. And so I'm thinking if we could just drop in some classes as resources, and those classes are just built manually and dropped and committed into the source... very very awkward, yes, but for the few cases we will endure it, and then the runtime won't be affected (no reflection used). Only, then some special test cases will be needed to check if those classes aren't out of sync with what they meant to link to and such. (BTW, we will also need the OSGi meta data, Manual building, etc. But all that when everything else is done.) -- Thanks, Daniel Dekany > Kind regards, > > Woonsan > > > -- Forwarded message -- > From: Daniel Dekany > Date: Sat, Oct 31, 2015 at 1:02 AM > Subject: Re: Question on unit testing > To: Woonsan Ko > > > It would be in fact very good news if this thing can go with Maven... > looking forward for the results! > > > Thursday, October 29, 2015, 10:54:50 AM, Woonsan Ko wrote: > >>>> By the way, IIRC, you mentioned in old ML that it's planned to migrate >>>> to Maven some day. Is
Re: Should freemarker.org remain the canonical domain?
Since then, ASF has agreed that we will use freemarker.org as the canonical domain (it will be fully hosted by ASF), and so I have asked Infra to turn around the domain redirection yesterday. So now I'm waiting for this to happen. -- Thanks, Daniel Dekany
Re: Adding a new BuiltIn - previousSibling
Friday, November 20, 2015, 8:51:31 AM, Pradeep Murugesan wrote:
> Hi Daniel,
>
> Took a long break due to some personal reasons. Sorry for the same. I have a
> question in your email.
>
> What do you mean by
>
> "Also I guess inside the testPreviousSibling you don't really need
> output capturing, nor ?trim. "
>
> I am not sure what you are coming to say there. We need to assert somehow the
> expected o/p right ?
>
> so we can't assert against empty spaces since we don't know how
> many spaces , So I thought of asserting the same after trimming the o/p.
We don't need capturing for sure, I guess you see that now. As of
trimming, that's a minor issue really, but in fact we know how many
spaces are there, since we provide the XML.
> Let me know if I am missing something.
>
> Pradeep.
>
> From: Daniel Dekany
> Sent: Tuesday, November 10, 2015 2:44 AM
> To: Pradeep Murugesan
> Subject: Re: Adding a new BuiltIn - previousSibling
>
> Tuesday, November 3, 2015, 7:19:17 AM, Pradeep Murugesan wrote:
>
>> Hi Daniel,
>>
>> I have made the changes you have said and writing unit tests. I
>> have written an unit test and need to check whether can I proceed in
>> the same fashion. One important question I have is accessing the
>> (XML) datamodel required for the testcase.
>>
>> Now I am overriding the function getDataModel() and read the xml
>> from a file. Kindly let me know if that is acceptable.
>
> You don't need to override getDateModel(). Just add "doc" to the data
> model with the TemplateTest.addToDataModel.
>
> Loading the XML file via java.io.File API is not entirely correct,
> especially not with that relative path ("build/test-classes/..."). You
> don't know what the current directory will be on the CI server for
> example. Also, though an extreme case, but it can also occur that a
> test suite is ran from an unexploded jar (i.e., you don't even have
> real files anywhere). Just like outside tests, the correct solution is
> using Class.getResource or Class.getResourceAsStream to read
> class-loader resources.
>
> Also I guess inside the testPreviousSibling you don't really need
> output capturing, nor ?trim.
>
>> https://github.com/pradeepmurugesan/incubator-freemarker/commit/42132df19b6f8e53f66ff3f6cbbce459376c65a6
>>
>>
>> P.S : I have removed the author name in next commit. Intellij adds
>> it and I am missing it everytime. Sorry!!.
>>
>> Pradeep.
>>
>>
>>
>>
>> From: Pradeep Murugesan
>> Sent: Thursday, October 29, 2015 7:46 AM
>> To: dev@freemarker.incubator.apache.org
>> Subject: Re: Adding a new BuiltIn - previousSibling
>>
>> oh now I got it.
>>
>> So we can also expect something like
>> there is some text here
>>
>> Now when the user do a @@previous on node 'b' he will get node 'a'
>> but he might expect "there is some text here" which is still a valid text
>> node.
>>
>> I thought there can be no such scenario so kept hanging on with
>> blindly skipping all till we get a node. So I will do the following .
>>
>> 1. rename to @@previous_significant
>> 2. skip the siblings when its in any of the blacklisted candidates.
>> ( whitespaces, CDATA, \n(ofcourse))
>>
>> Pradeep.
>>
>>
>> From: Daniel Dekany
>> Sent: Thursday, October 29, 2015 4:12 AM
>> To: Pradeep Murugesan
>> Subject: Re: Adding a new BuiltIn - previousSibling
>>
>> Wednesday, October 28, 2015, 6:21:19 PM, Pradeep Murugesan wrote:
>>
>>> Hi Daniel,
>>>
>>> I agree with that but I have a question kindly don't take it as an
>>> argument. Just curious to know
>>>
>>> 1. cdata
>>> 2.\n
>>> 3. comments
>>> 4. some PI's
>>>
>>> In all the above 4 scenarios when we do a @@previous on node 'b' we expect
>>> node 'a'.
>>
>> With what you have implemented so far, that is.
>>
>>> I am suggesting we will keep iterating until we find a node type
>>> ELEMENT_NODE and return it.
>>> you are suggesting to keep iterating until we find a node that is not in
>>> \n, CDATA, PIs etc.
>>>
>>> I think both will work. Do you think any of it which should be
>>> skipped will also have node type ELEMENT_NODE.
>>
>> Nope.
>>
>>> I am not sure
Improve search on freemarker.org
In practice I have found some problems with search on freemarker.org: - I can't search in the API java docs. - When I search in the Manual, I often also want hits from the API JavaDocs, though getting them wouldn't be logical because of the structure of the site. - There's no search box on the Home tab. People my not realize that there's on on the Manual tab. So I think we need a global search box, which by default searches in the Manual and in the JavaDocs too. It would be a plus if it has "API" and "Manual" check boxes. So that would address all the point above. Where to put the global search box (layout...) is a trickier question. Certainly the Contribut-Report-Download thing had to go away to give space to it, but instead perhaps we could make them more apparent in the side menu (with some icons or whatever). And then on the Manual there will be a void in place of search... I don't know. Can you figure out something awesome? :) - The search box is no re-filled after search, so I can't refine my search. -- Thanks, Daniel Dekany
Re: Improve search on freemarker.org
Sunday, November 22, 2015, 9:30:49 AM, Lee wrote: > For the homepage we could add a search link that opens when the > user clicks on it... then on the manual we could add the checkboxes > when the user focuses on the search box. (These are just a quick > sketch, the design would look more polished when finished) Sounds good! -- Thanks, Daniel Dekany > I can also fix the search box not being refilled, too > > On Sat, Nov 21, 2015 at 12:49 AM, Daniel Dekany wrote: > In practice I have found some problems with search on freemarker.org: > > - I can't search in the API java docs. > > - When I search in the Manual, I often also want hits from the API > JavaDocs, though getting them wouldn't be logical because of the > structure of the site. > > - There's no search box on the Home tab. People my not realize that > there's on on the Manual tab. > > So I think we need a global search box, which by default searches in > the Manual and in the JavaDocs too. It would be a plus if it has > "API" and "Manual" check boxes. So that would address all the point > above. > > Where to put the global search box (layout...) is a trickier > question. Certainly the Contribut-Report-Download thing had to go > away to give space to it, but instead perhaps we could make them > more apparent in the side menu (with some icons or whatever). And > then on the Manual there will be a void in place of search... I > don't know. Can you figure out something awesome? > > - The search box is no re-filled after search, so I can't refine my > search. > > -- > Thanks, > Daniel Dekany
Re: Improve search on freemarker.org
Something is off with Google Custom Search... maybe it's a local or temporal issue, I don't know. As an experiment, try to search for "Using FreeMarker with servlets" with quotation marks(!). For me, it won't find the page whose title that is. Instead it finds a dozen of pages where that expression occurs in the side ToC (which ideally should not be considered at all). On the same time, plain Google gives the desired page as first hit. Also, now I get JavaDoc hits mixed with Manual hits, despite of what I have experienced earlier (no search in JavaDoc). It's not necessarily bad, I just didn't know that we have changed this... did we? -- Thanks, Daniel Dekany Saturday, November 21, 2015, 9:49:29 AM, Daniel Dekany wrote: > In practice I have found some problems with search on freemarker.org: > > - I can't search in the API java docs. > > - When I search in the Manual, I often also want hits from the API > JavaDocs, though getting them wouldn't be logical because of the > structure of the site. > > - There's no search box on the Home tab. People my not realize that > there's on on the Manual tab. > > So I think we need a global search box, which by default searches in > the Manual and in the JavaDocs too. It would be a plus if it has > "API" and "Manual" check boxes. So that would address all the point > above. > > Where to put the global search box (layout...) is a trickier > question. Certainly the Contribut-Report-Download thing had to go > away to give space to it, but instead perhaps we could make them > more apparent in the side menu (with some icons or whatever). And > then on the Manual there will be a void in place of search... I > don't know. Can you figure out something awesome? :) > > - The search box is no re-filled after search, so I can't refine my > search. >
Re: Improve search on freemarker.org
I have fixed the Ivy repo checksum issue (was a CRLF VS LF problem). Delete docgen/.ivy and try again! Saturday, November 28, 2015, 7:48:12 PM, Lee wrote: > I'm looking at it right now actually... > > Also, I can't get docgen to build on my windows machine: > > > [ivy:retrieve] > [ivy:retrieve] :: problems summary :: > [ivy:retrieve] WARNINGS > [ivy:retrieve] problem while downloading module descriptor: > http://freemarker.org/repos/ivy/org.freemarker/freemarker/ivy-2.3-branch-head.xml: > invalid sha1: ex > pected=fc7faac4643441acd716abe4f05f635d813c2b74 > computed=41ac97d45442e9b4cdda55f221d3c47b329159e2 (1084ms) > [ivy:retrieve] module not found: > org.freemarker#freemarker;2.3-branch-head > [ivy:retrieve] freemarker-devel-webserver: tried > [ivy:retrieve] > http://freemarker.org/repos/ivy/org.freemarker/freemarker/ivy-2.3-branch-head.xml > [ivy:retrieve] :: > [ivy:retrieve] :: UNRESOLVED DEPENDENCIES :: > [ivy:retrieve] :: > [ivy:retrieve] :: > org.freemarker#freemarker;2.3-branch-head: not found > [ivy:retrieve] :: > [ivy:retrieve] > [ivy:retrieve] > [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS > > On Sat, Nov 28, 2015 at 1:51 AM, Daniel Dekany wrote: > Something is off with Google Custom Search... maybe it's a local or > temporal issue, I don't know. > > As an experiment, try to search for "Using FreeMarker with servlets" > with quotation marks(!). For me, it won't find the page whose title > that is. Instead it finds a dozen of pages where that expression > occurs in the side ToC (which ideally should not be considered at > all). On the same time, plain Google gives the desired page as first > hit. > > Also, now I get JavaDoc hits mixed with Manual hits, despite of what I > have experienced earlier (no search in JavaDoc). It's not necessarily > bad, I just didn't know that we have changed this... did we? > > -- > Thanks, > Daniel Dekany > > > Saturday, November 21, 2015, 9:49:29 AM, Daniel Dekany wrote: > >> In practice I have found some problems with search on freemarker.org: >> >> - I can't search in the API java docs. >> >> - When I search in the Manual, I often also want hits from the API >> JavaDocs, though getting them wouldn't be logical because of the >> structure of the site. >> >> - There's no search box on the Home tab. People my not realize that >> there's on on the Manual tab. >> >> So I think we need a global search box, which by default searches in >> the Manual and in the JavaDocs too. It would be a plus if it has >> "API" and "Manual" check boxes. So that would address all the point >> above. >> >> Where to put the global search box (layout...) is a trickier >> question. Certainly the Contribut-Report-Download thing had to go >> away to give space to it, but instead perhaps we could make them >> more apparent in the side menu (with some icons or whatever). And >> then on the Manual there will be a void in place of search... I >> don't know. Can you figure out something awesome? >> >> - The search box is no re-filled after search, so I can't refine my >> search. >> > > -- Thanks, Daniel Dekany
Re: Improve search on freemarker.org
BTW, you can now update the site by committing into the "asf-site" branch of the "site" repo. As you will see when you check it out, it contains the files on the web server as is. Sunday, November 29, 2015, 1:36:32 AM, Daniel Dekany wrote: > I have fixed the Ivy repo checksum issue (was a CRLF VS LF problem). > Delete docgen/.ivy and try again! > > > Saturday, November 28, 2015, 7:48:12 PM, Lee wrote: > >> I'm looking at it right now actually... >> >> Also, I can't get docgen to build on my windows machine: >> >> >> [ivy:retrieve] >> [ivy:retrieve] :: problems summary :: >> [ivy:retrieve] WARNINGS >> [ivy:retrieve] problem while downloading module descriptor: >> http://freemarker.org/repos/ivy/org.freemarker/freemarker/ivy-2.3-branch-head.xml: >> invalid sha1: ex >> pected=fc7faac4643441acd716abe4f05f635d813c2b74 >> computed=41ac97d45442e9b4cdda55f221d3c47b329159e2 (1084ms) >> [ivy:retrieve] module not found: >> org.freemarker#freemarker;2.3-branch-head >> [ivy:retrieve] freemarker-devel-webserver: tried >> [ivy:retrieve] >> http://freemarker.org/repos/ivy/org.freemarker/freemarker/ivy-2.3-branch-head.xml >> [ivy:retrieve] :: >> [ivy:retrieve] :: UNRESOLVED DEPENDENCIES :: >> [ivy:retrieve] :: >> [ivy:retrieve] :: >> org.freemarker#freemarker;2.3-branch-head: not found >> [ivy:retrieve] :::::::::: >> [ivy:retrieve] >> [ivy:retrieve] >> [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS >> >> On Sat, Nov 28, 2015 at 1:51 AM, Daniel Dekany wrote: >> Something is off with Google Custom Search... maybe it's a local or >> temporal issue, I don't know. >> >> As an experiment, try to search for "Using FreeMarker with servlets" >> with quotation marks(!). For me, it won't find the page whose title >> that is. Instead it finds a dozen of pages where that expression >> occurs in the side ToC (which ideally should not be considered at >> all). On the same time, plain Google gives the desired page as first >> hit. >> >> Also, now I get JavaDoc hits mixed with Manual hits, despite of what I >> have experienced earlier (no search in JavaDoc). It's not necessarily >> bad, I just didn't know that we have changed this... did we? >> >> -- >> Thanks, >> Daniel Dekany >> >> >> Saturday, November 21, 2015, 9:49:29 AM, Daniel Dekany wrote: >> >>> In practice I have found some problems with search on freemarker.org: >>> >>> - I can't search in the API java docs. >>> >>> - When I search in the Manual, I often also want hits from the API >>> JavaDocs, though getting them wouldn't be logical because of the >>> structure of the site. >>> >>> - There's no search box on the Home tab. People my not realize that >>> there's on on the Manual tab. >>> >>> So I think we need a global search box, which by default searches in >>> the Manual and in the JavaDocs too. It would be a plus if it has >>> "API" and "Manual" check boxes. So that would address all the point >>> above. >>> >>> Where to put the global search box (layout...) is a trickier >>> question. Certainly the Contribut-Report-Download thing had to go >>> away to give space to it, but instead perhaps we could make them >>> more apparent in the side menu (with some icons or whatever). And >>> then on the Manual there will be a void in place of search... I >>> don't know. Can you figure out something awesome? >>> >>> - The search box is no re-filled after search, so I can't refine my >>> search. >>> >> >> > -- Thanks, Daniel Dekany
Is it time to start a FreeMarker 3 branch?
I was wondering if for how long should we add major features to the backward compatibility bound 2.3+ line (2.3.x, and 2.4.x). With FreeMarker 3 I mean shamelessly dropping BC (while remaining recognizable), move the existing code base to a different package (like org.apache.freemarker3 or org.freemarker.v3) so that it can be used in parallel with FreeMarker 2, and cleaning it up from all the historical mistakes (this includes syntactical adjustments, introducing FTL3). I'm thinking in refactoring/cleanup in smaller steps, and rewriting as few parts as possible (like the parser). Doing this is possibly a turndown for 2.x user, but after 11 years since 2.3.0, and nearly 0 contribution from the companies relying on FM, doing this is perhaps not that outrageous. And it's not like 2.3 won't get fixes or even smaller backported features. Anyway, why do I think it should be done: * Development costs: It's possible to play a round with the incompatibleImprovements setting in 2.x almost indefinitely, but the more fundamental legacy issues you address, the more expensive it is in terms of developer time to make that fix optional (i.e., something you can turn on via incompatibleImprovements), and developer time is scarce. I'm afraid that without cutting these expenses, most of the deeper fixes will just never happen or happen too late, also new/innovative features will delay too much. * Complexity pushed on the user: The sometimes confusing legacy public API and the growing amount of legacy/redundant features, which are confusing for the user, you can't fix with incompatibleImprovements. So while users who are dependant on 2.x are possibly better of with messing with this additional complexity (on the short term at least), all the new users are negatively affected. * Attractiveness for new developers: Dragging all the legacy with us means substantial additional code complexity and code ugliness. Thus contributions are harder to make, and most importantly, long term developers are hard to catch. (Some may ask, what about 2.4? I have kept putting things into 2.3 that were meant for 2.4... like Java 5. I just don't know when and if anyone will find the energy to release 2.4, for the few remaining things must remain 2.4-exclusive.) You may ask what I want to change: - Dropping all the not-recommended-anymore and deprecated features, obviously. There's a lot, trust me... - Rename things that has confusing name, or are in the wrong package - Unify the concept of macros and (user-defined-)directives. Same with functions and methods. These are separate concepts yet similar in the current code base. - Parser/syntax: - FTL3: - Null-aware, has a behavior that's more like Groovy's - Hash "map" type instead of "hash" (i.e., no string-keys-only BS anymore) - Better whitespace handling - Has simpler, more regular syntax. - Designed to make user-defined dialects possible - Some minor changes in expression syntax... doesn't mater for now. - Separately pluggable expression language and "outer" language - Made with IDE and template-introspection support in mind - Template loading/caching: - A better version of the TemplateLoader mechanism. The current one has problems with being effective with DB for example. - In general, template loading/caching need to be more pluggable. Right now it's often hard to reuse your framework's existing caching facility for example. So that's a FM 3.0, plus whatever I have forgotten about. That's a lot of work you see there, but it's rewarding. -- Thanks, Daniel Dekany
Re: Is it time to start a FreeMarker 3 branch?
Sunday, November 29, 2015, 11:28:31 AM, Daniel Dekany wrote: [snip] > - Dropping all the not-recommended-anymore and deprecated features, > obviously. There's a lot, trust me... > - Rename things that has confusing name, or are in the wrong package > - Unify the concept of macros and (user-defined-)directives. Same with > functions and methods. These are separate concepts yet similar in > the current code base. > - Parser/syntax: > - FTL3: > - Null-aware, has a behavior that's more like Groovy's > - Hash "map" type instead of "hash" (i.e., no string-keys-only BS > anymore) > - Better whitespace handling > - Has simpler, more regular syntax. > - Designed to make user-defined dialects possible > - Some minor changes in expression syntax... doesn't mater for now. > - Separately pluggable expression language and "outer" language > - Made with IDE and template-introspection support in mind > - Template loading/caching: > - A better version of the TemplateLoader mechanism. The current one > has problems with being effective with DB for example. > - In general, template loading/caching need to be more pluggable. > Right now it's often hard to reuse your framework's existing > caching facility for example. > > So that's a FM 3.0, plus whatever I have forgotten about. That's a lot > of work you see there, but it's rewarding. And one that I have forgotten: - Modularize FM. There should be a bare-bone engine Maven module, and then a separate Servlet Maven module, a JSP Maven module, Jython module (if there's still interest in that), etc. (Maybe even XML support should be separate.) This will also help to migrate the project build to to Maven. Another aspect of this is that 3.0 can be released without all the other modules to be cleaned up and ready (especially Serlvet/JSP will be a substantial work). -- Thanks, Daniel Dekany
Re: Is it time to start a FreeMarker 3 branch?
Tuesday, December 1, 2015, 6:30:48 PM, Lee wrote:
> FreeMarker 3 could be beneficial. What does this item mean?
> "Separately pluggable expression language and "outer" language"
In a (typical) template language, you have static text sections (i.e.
raw output) on the top level, and then there's some template language
sections embedded into that (interpolations and FTL tags in our case)
with some delimiters (`${...}`, `<#name ...>, etc. in our case). So
those are basically the things defined by the "outer language".
Between these delimiters you are using some "expression language".
Why replaceable outer language matters? First of all, the outer
language sometimes clashes with the static text (like you have to
write templates for a scripts or JSP that already uses ${...} a lot,
which hence you had to escape out). Secondly, during the years I have
found that the look-and-feel of the outer language is something that
people tend to be sentimental about. Like many reject FreeMarker
because they find `<#name ...>` scary/ugly, while they have no problem
with `#name(...)...#end` (Velocitish syntax), or `#name(...) {...}`
(Webmacroish syntax), even if it means the same.
Why replaceable expression language matters? I'm not so happy about
that, but anyway, if you are working with a certainly language, and
then you switch to editing a template, for many it's annoying to
switch their brain to FTL expression language syntax. Then there's the
approach where you just use another language to calculate expression
values... something that will be interesting to explore, but it's a
quite tricky problem. Like, let's say you use JavaScript expressions
via Nashorn. What corresponds to "foo?someBuiltIn", for example? If
FTL will have `:` as in XML, what will correspond to that? Etc.
Anyway, for FTL3, I think the point is just having these two languages
separated. So later it will be possible to play around with replacing
at least the outer language.
--
Thanks,
Daniel Dekany
> On Sun, Nov 29, 2015 at 3:07 AM, Daniel Dekany wrote:
> Sunday, November 29, 2015, 11:28:31 AM, Daniel Dekany wrote:
>
> [snip]
>> - Dropping all the not-recommended-anymore and deprecated features,
>> obviously. There's a lot, trust me...
>> - Rename things that has confusing name, or are in the wrong package
>> - Unify the concept of macros and (user-defined-)directives. Same with
>> functions and methods. These are separate concepts yet similar in
>> the current code base.
>> - Parser/syntax:
>> - FTL3:
>> - Null-aware, has a behavior that's more like Groovy's
>> - Hash "map" type instead of "hash" (i.e., no string-keys-only BS
>> anymore)
>> - Better whitespace handling
>> - Has simpler, more regular syntax.
>> - Designed to make user-defined dialects possible
>> - Some minor changes in expression syntax... doesn't mater for now.
>> - Separately pluggable expression language and "outer" language
>> - Made with IDE and template-introspection support in mind
>> - Template loading/caching:
>> - A better version of the TemplateLoader mechanism. The current one
>> has problems with being effective with DB for example.
>> - In general, template loading/caching need to be more pluggable.
>> Right now it's often hard to reuse your framework's existing
>> caching facility for example.
>>
>> So that's a FM 3.0, plus whatever I have forgotten about. That's a lot
>> of work you see there, but it's rewarding.
>
> And one that I have forgotten:
>
> - Modularize FM. There should be a bare-bone engine Maven module, and
> then a separate Servlet Maven module, a JSP Maven module, Jython
> module (if there's still interest in that), etc. (Maybe even XML
> support should be separate.) This will also help to migrate the
> project build to to Maven. Another aspect of this is that 3.0 can be
> released without all the other modules to be cleaned up and ready
> (especially Serlvet/JSP will be a substantial work).
>
> --
> Thanks,
> Daniel Dekany
Re: Is it time to start a FreeMarker 3 branch?
As far as I'm concerned, as far as we can be inside ASF, that's what it will be. -- Thanks, Daniel Dekany Tuesday, December 1, 2015, 6:58:07 PM, Woonsan Ko wrote: > +1 on all you described for FTL3. > > Just a side note, I like 'org.apache.freemarker3' better as new > package name. I saw a similar pattern in Apache Commons. e.g, > org.apache.commons.lang3. > > Regards, > > Woonsan > > > On Sun, Nov 29, 2015 at 6:07 AM, Daniel Dekany wrote: >> Sunday, November 29, 2015, 11:28:31 AM, Daniel Dekany wrote: >> >> [snip] >>> - Dropping all the not-recommended-anymore and deprecated features, >>> obviously. There's a lot, trust me... >>> - Rename things that has confusing name, or are in the wrong package >>> - Unify the concept of macros and (user-defined-)directives. Same with >>> functions and methods. These are separate concepts yet similar in >>> the current code base. >>> - Parser/syntax: >>> - FTL3: >>> - Null-aware, has a behavior that's more like Groovy's >>> - Hash "map" type instead of "hash" (i.e., no string-keys-only BS >>> anymore) >>> - Better whitespace handling >>> - Has simpler, more regular syntax. >>> - Designed to make user-defined dialects possible >>> - Some minor changes in expression syntax... doesn't mater for now. >>> - Separately pluggable expression language and "outer" language >>> - Made with IDE and template-introspection support in mind >>> - Template loading/caching: >>> - A better version of the TemplateLoader mechanism. The current one >>> has problems with being effective with DB for example. >>> - In general, template loading/caching need to be more pluggable. >>> Right now it's often hard to reuse your framework's existing >>> caching facility for example. >>> >>> So that's a FM 3.0, plus whatever I have forgotten about. That's a lot >>> of work you see there, but it's rewarding. >> >> And one that I have forgotten: >> >> - Modularize FM. There should be a bare-bone engine Maven module, and >> then a separate Servlet Maven module, a JSP Maven module, Jython >> module (if there's still interest in that), etc. (Maybe even XML >> support should be separate.) This will also help to migrate the >> project build to to Maven. Another aspect of this is that 3.0 can be >> released without all the other modules to be cleaned up and ready >> (especially Serlvet/JSP will be a substantial work). >> >> -- >> Thanks, >> Daniel Dekany >> >
Re: Is it time to start a FreeMarker 3 branch?
Even more additions to this:
- Of course, first of all we have to get 2.3.24 to be released (RC1
first). There's quite a few important new features in it. It would
be good if some of you try to find the problems with the new API-s
and features. Not just bugs, but design issues. Those can't be fixed
later.
- I will create a list of new features which I think must be
implemented for FTL3 to be releasable. And then, I will pick those
that can be put into 2.3 without too much overhead, and implement
them in 2.3.
- Another heavy change that I consider in FTL3 is making variable
"creation" more static, and more familiar looking. People often want
to be able to tell programmatically what model variables are used in
a template, but with ad-hoc created variables it's not possible to
tell reliably. Plus, I think #assign/#local/#global (and esp.
#assign) is ugly. I think, #var and #set is much cuter, where #set
without corresponding #var is a "compilation" time error (hence can
also be marked by editor plugins). (You might know the annoyance
when you make a typo in the assigned variable name, but you don't
get an error, not even on runtime, and it silently creates a new
variable). I would also make #var scoped by the closest enclosing
block (like `let` in ES6). So #var naturally takes the role of
#local too. What about #global, etc.? I think we will need `:` as in
XML anyway, so it can be <#set global:x = 123> and ${global:x} or
like. So what I'm shooting for is that if you have a `${x}` then you
can tell (syntax-highlight) right in the editor if it's a data-model
variable or a template-created variable (#var or macro/function
argument).
--
Thanks,
Daniel Dekany
Sunday, November 29, 2015, 12:07:15 PM, Daniel Dekany wrote:
> Sunday, November 29, 2015, 11:28:31 AM, Daniel Dekany wrote:
>
> [snip]
>> - Dropping all the not-recommended-anymore and deprecated features,
>> obviously. There's a lot, trust me...
>> - Rename things that has confusing name, or are in the wrong package
>> - Unify the concept of macros and (user-defined-)directives. Same with
>> functions and methods. These are separate concepts yet similar in
>> the current code base.
>> - Parser/syntax:
>> - FTL3:
>> - Null-aware, has a behavior that's more like Groovy's
>> - Hash "map" type instead of "hash" (i.e., no string-keys-only BS
>> anymore)
>> - Better whitespace handling
>> - Has simpler, more regular syntax.
>> - Designed to make user-defined dialects possible
>> - Some minor changes in expression syntax... doesn't mater for now.
>> - Separately pluggable expression language and "outer" language
>> - Made with IDE and template-introspection support in mind
>> - Template loading/caching:
>> - A better version of the TemplateLoader mechanism. The current one
>> has problems with being effective with DB for example.
>> - In general, template loading/caching need to be more pluggable.
>> Right now it's often hard to reuse your framework's existing
>> caching facility for example.
>>
>> So that's a FM 3.0, plus whatever I have forgotten about. That's a lot
>> of work you see there, but it's rewarding.
>
> And one that I have forgotten:
>
> - Modularize FM. There should be a bare-bone engine Maven module, and
> then a separate Servlet Maven module, a JSP Maven module, Jython
> module (if there's still interest in that), etc. (Maybe even XML
> support should be separate.) This will also help to migrate the
> project build to to Maven. Another aspect of this is that 3.0 can be
> released without all the other modules to be cleaned up and ready
> (especially Serlvet/JSP will be a substantial work).
>
Re: Is it time to start a FreeMarker 3 branch?
Actually, yes, that's even better. (If there ever will be a FM 4, it can still use org.apache.freemarker4 after all.) Tuesday, December 1, 2015, 11:05:03 PM, Jacques Le Roux wrote: > To keep things simple why not org.apache.freemarker? > > Jacques > > Le 01/12/2015 18:58, Woonsan Ko a écrit : >> +1 on all you described for FTL3. >> >> Just a side note, I like 'org.apache.freemarker3' better as new >> package name. I saw a similar pattern in Apache Commons. e.g, >> org.apache.commons.lang3. >> >> Regards, >> >> Woonsan >> >> >> On Sun, Nov 29, 2015 at 6:07 AM, Daniel Dekany wrote: >>> Sunday, November 29, 2015, 11:28:31 AM, Daniel Dekany wrote: >>> >>> [snip] >>>> - Dropping all the not-recommended-anymore and deprecated features, >>>>obviously. There's a lot, trust me... >>>> - Rename things that has confusing name, or are in the wrong package >>>> - Unify the concept of macros and (user-defined-)directives. Same with >>>>functions and methods. These are separate concepts yet similar in >>>>the current code base. >>>> - Parser/syntax: >>>>- FTL3: >>>> - Null-aware, has a behavior that's more like Groovy's >>>> - Hash "map" type instead of "hash" (i.e., no string-keys-only BS >>>>anymore) >>>> - Better whitespace handling >>>> - Has simpler, more regular syntax. >>>> - Designed to make user-defined dialects possible >>>> - Some minor changes in expression syntax... doesn't mater for now. >>>>- Separately pluggable expression language and "outer" language >>>>- Made with IDE and template-introspection support in mind >>>> - Template loading/caching: >>>>- A better version of the TemplateLoader mechanism. The current one >>>> has problems with being effective with DB for example. >>>>- In general, template loading/caching need to be more pluggable. >>>> Right now it's often hard to reuse your framework's existing >>>> caching facility for example. >>>> >>>> So that's a FM 3.0, plus whatever I have forgotten about. That's a lot >>>> of work you see there, but it's rewarding. >>> And one that I have forgotten: >>> >>> - Modularize FM. There should be a bare-bone engine Maven module, and >>>then a separate Servlet Maven module, a JSP Maven module, Jython >>>module (if there's still interest in that), etc. (Maybe even XML >>>support should be separate.) This will also help to migrate the >>>project build to to Maven. Another aspect of this is that 3.0 can be >>>released without all the other modules to be cleaned up and ready >>>(especially Serlvet/JSP will be a substantial work). >>> >>> -- >>> Thanks, >>> Daniel Dekany >>> > -- Thanks, Daniel Dekany --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Communication between directives
Friday, December 4, 2015, 8:44:12 PM, Ingo Mahnke wrote: > Hallo! > I am new to freemarker and I have one question perhaps sombody can help me. > I have two own directives written in Java and one Template: > > > <@group name="qname" label="Header" render="collapse" id="header"> ><@select name="kjkjk"/> > > > When I am inside the execute method of "select" I need access to > the next parent "group"-Element and I need the > value of the "name" attribute. Is this kind of communication between > directives possible? There's no dedicated feature for it (there should be...), but it's still possible. Both kind of directives (one implemented as an FTL macro, the other in Java as TemplateDirectiveModel, I assume) can read and write the so called global variables. Global variables live inside the Environment object, of which a new one is created for each Template.process call. In FTL, you create/modify globals as <#global myVar = someValue>, and just read them as any other variable (assuming it's not shadowed by another, but then you can still use .globals.myVar). In Java, you can use Environment.getGlobalVariable and setGlobalVariable. Of course, you should chose a sufficiently unique global variable name, like myLib_group_name. > Thank you! > Ingo -- Thanks, Daniel Dekany --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Improve search on freemarker.org
BTW, the Google Custom Search still behaves rather strangely. Like if I repeat the original experiment, searching for "Using FreeMarker with servlets" with quotation marks, now it only gives one hit, http://freemarker.incubator.apache.org/docs/xgui_declarative.html, which doesn't even contain that expression. I don't know what's wrong with it... maybe the domain change has driven it crazy? (I have asked Infra to make freemarker.org canonical about 2 weeks ago, but there's no reaction so far.) -- Thanks, Daniel Dekany Sunday, November 29, 2015, 6:59:07 AM, Lee wrote: > I fixed the issue where the search box doesn't get prepopulated. I also > upgraded some of the npm packages. If you are on an old version of NodeJS, > you should upgrade (should be at least 0.12.4) > > On Sat, Nov 28, 2015 at 9:19 PM, Lee wrote: > >> Cool, thanks! Ivy is working now : ) >> >> On Sat, Nov 28, 2015 at 4:45 PM, Daniel Dekany >> wrote: >> >>> BTW, you can now update the site by committing into the "asf-site" >>> branch of the "site" repo. As you will see when you check it out, it >>> contains the files on the web server as is. >>> >>> >>> Sunday, November 29, 2015, 1:36:32 AM, Daniel Dekany wrote: >>> >>> > I have fixed the Ivy repo checksum issue (was a CRLF VS LF problem). >>> > Delete docgen/.ivy and try again! >>> > >>> > >>> > Saturday, November 28, 2015, 7:48:12 PM, Lee wrote: >>> > >>> >> I'm looking at it right now actually... >>> >> >>> >> Also, I can't get docgen to build on my windows machine: >>> >> >>> >> >>> >> [ivy:retrieve] >>> >> [ivy:retrieve] :: problems summary :: >>> >> [ivy:retrieve] WARNINGS >>> >> [ivy:retrieve] problem while downloading module descriptor: >>> >> >>> http://freemarker.org/repos/ivy/org.freemarker/freemarker/ivy-2.3-branch-head.xml: >>> invalid sha1: ex >>> >> pected=fc7faac4643441acd716abe4f05f635d813c2b74 >>> >> computed=41ac97d45442e9b4cdda55f221d3c47b329159e2 (1084ms) >>> >> [ivy:retrieve] module not found: >>> >> org.freemarker#freemarker;2.3-branch-head >>> >> [ivy:retrieve] freemarker-devel-webserver: tried >>> >> [ivy:retrieve] >>> >> >>> http://freemarker.org/repos/ivy/org.freemarker/freemarker/ivy-2.3-branch-head.xml >>> >> [ivy:retrieve] :::::: >>> >> [ivy:retrieve] :: UNRESOLVED DEPENDENCIES :: >>> >> [ivy:retrieve] :: >>> >> [ivy:retrieve] :: >>> >> org.freemarker#freemarker;2.3-branch-head: not found >>> >> [ivy:retrieve] :: >>> >> [ivy:retrieve] >>> >> [ivy:retrieve] >>> >> [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS >>> >> >>> >> On Sat, Nov 28, 2015 at 1:51 AM, Daniel Dekany >>> wrote: >>> >> Something is off with Google Custom Search... maybe it's a local or >>> >> temporal issue, I don't know. >>> >> >>> >> As an experiment, try to search for "Using FreeMarker with servlets" >>> >> with quotation marks(!). For me, it won't find the page whose title >>> >> that is. Instead it finds a dozen of pages where that expression >>> >> occurs in the side ToC (which ideally should not be considered at >>> >> all). On the same time, plain Google gives the desired page as first >>> >> hit. >>> >> >>> >> Also, now I get JavaDoc hits mixed with Manual hits, despite of what I >>> >> have experienced earlier (no search in JavaDoc). It's not necessarily >>> >> bad, I just didn't know that we have changed this... did we? >>> >> >>> >> -- >>> >> Thanks, >>> >> Daniel Dekany >>> >> >>> >> >>> >> Saturday, November 21, 2015, 9:49:29 AM, Daniel Dekany wrote: >>> >> >>> >>> In practice I have found some problems with search on freemarker.org: >>> >>> >>> >>> - I can't search in the API java docs. >>> >>> >>> >>> - When I se
Re: Aw: Re: Communication between directives
Saturday, December 5, 2015, 12:18:17 PM, Ingo Mahnke wrote: > > Thank you, global variables Sounds good. > What's with cascading? > > <@group name="qname" label="Header" render="collapse" id="header"> ><@select name="kjkjk"/> > <@group name="def" label="SubHeader" render="collapse" id="subheader"> > <@select name="abck"/> > > <@select name="kjkjk2"/> > Well, that's one of the things why a dedicated feature would be better, but anyway, it's still possible, even if it's a bit verbose. For example, you could have a last_myLib_group_name: <#macro group name> <#global last_myLib_group_name=myLib_group_name!> <#global myLib_group_name=name> .. <#nested> .. <#global myLib_group_name=last_myLib_group_name> One caveat you will run into here is that for the outermost group, the last #global assignment will restore myLib_group_name to be "" instead of to be non-existant... so then that's something you have to consider in @select: an empty name means you have no enclosing @group, which should just be an error, instead of going on with an empty name. But if I was heavily relying on something like this, I would consider using some helper directive for this, that can manage a "stack" of values (an List technically). -- Thanks, Daniel Dekany >> Gesendet: Samstag, 05. Dezember 2015 um 01:07 Uhr >> Von: "Daniel Dekany" >> An: "Ingo Mahnke" >> Cc: dev@freemarker.incubator.apache.org >> Betreff: Re: Communication between directives >> >> Friday, December 4, 2015, 8:44:12 PM, Ingo Mahnke wrote: >> >> > Hallo! >> > I am new to freemarker and I have one question perhaps sombody can help me. >> > I have two own directives written in Java and one Template: >> > >> > >> > <@group name="qname" label="Header" render="collapse" id="header"> >> ><@select name="kjkjk"/> >> > >> > >> > When I am inside the execute method of "select" I need access to >> > the next parent "group"-Element and I need the >> > value of the "name" attribute. Is this kind of communication between >> > directives possible? >> >> There's no dedicated feature for it (there should be...), but it's >> still possible. Both kind of directives (one implemented as an FTL >> macro, the other in Java as TemplateDirectiveModel, I assume) can read >> and write the so called global variables. Global variables live inside >> the Environment object, of which a new one is created for each >> Template.process call. In FTL, you create/modify globals as >> <#global myVar = someValue>, and just read them as any other variable >> (assuming it's not shadowed by another, but then you can still use >> .globals.myVar). In Java, you can use Environment.getGlobalVariable >> and setGlobalVariable. Of course, you should chose a sufficiently >> unique global variable name, like myLib_group_name. >> >> > Thank you! >> > Ingo >> >> -- >> Thanks, >> Daniel Dekany >> >> >> --- >> This email has been checked for viruses by Avast antivirus software. >> https://www.avast.com/antivirus >> >> > -- Thanks, Daniel Dekany --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
