Re: Scope of variable for <#nested> while using #import
Wednesday, November 22, 2017, 7:14:34 AM, Swapnil Mane wrote:
> Dear Daniel,
>
> Thank you so much for your kind inputs.
> Passing back values in nested works for me.
>
> Please see my comments inline.
>
> On Sat, Nov 18, 2017 at 12:50 AM, Daniel Dekany wrote:
>
>> Friday, November 17, 2017, 3:55:22 PM, Daniel Dekany wrote:
>>
>> > #assign sets the variable in the current namespace. Each #include-d
>>
>> I wanted to write #import"-ed above... #include-d templates use the
>> namespace of the includer.
>>
>> > template has its own namespace, plus the the topmost template has its
>> > own namespace (the "main" namespace). So if you use #assign like that,
>> > then in the other namespace you had to write ${widget.name}. You might
>> > want to use #global instead, and then the variable is visible from
>> > everywhere (unless it's shadowed by a variable of the same name in the
>> > same namespace). (It's also possible to pass back a value like
>> > <#nested "FreeMarker World"> and then
>> > <@widget.getName ; name>${name}. Also you should write
>> > a #function if you just want to get a value, not a macro, as that has
>> > a return value.)
>>
>
> My bad, I used wrong example here (*getName*), actually I want multiple
> values for #nested code.
> like
>
> Defining macro
> <#macro linkInfo>
> <#local name = "FreeMarker World"/>
> <#local url = "https://freemarker.apache.org/"/>
> <#nested name, url>
>
>
> Using the defined macro
>
> <#import
> "component://hwmapps/template/commerce/templates/Widgets.ftl" as
e/>>
> <@e.linkInfo ; name, url>
> ${name!}
>
>
>
> So, in my case, I think, macro is needed instead of function.
Another possibility is returning (or pass via #nested) a single hash
value, like { "name": "Foo", "url": "http://foo.bar"; }, and then,
assuming that r is the returned value, you can use r.name and r.url.
>> > See also: https://freemarker.apache.org/docs/dgui_misc_namespace.html
>> >
>> >
>> > Friday, November 17, 2017, 1:56:03 PM, Swapnil Mane wrote:
>> >
>> >> Dear FreeMarker team,
>> >>
>> >> First I would like to thank you for creating such a nice template
>> engine, I
>> >> personally liked it very much :-)
>> >>
>> >> I need your help in an issue,
>> >>
>> >> While using <#nested>, the variable I defined using assign is not
>> >> accessible in nested code.
>> >>
>> >> Here is the more details
>> >>
>> >> 1.) I have a macro file having Widgets.ftl
>> >>
>> >> {code}
>> >>
>> >> <#macro getName>
>> >> <#assign name = "FreeMarker World"/>
>> >> <#nested>
>> >>
>> >>
>> >> {code}
>> >>
>> >> 2.) I have included the above file in another file using <#import>
>> >>
>> >> {code}
>> >>
>> >> <#import "Widgets.ftl" as widget>
>> >> <@widget.getName>
>> >> Hi ${name!}
>> >>
>> >>
>> >> {code}
>> >>
>> >> Expected output - Hi FreeMarker World
>> >> Actual output - Hi
>> >>
>> >>
>> >> Here the value of 'name' variable is not setting properly if assign is
>> used.
>> >> But when I set it using global, everything work as expected.
>> >>
>> >> {code}
>> >> <#global name = "FreeMarker World"/>
>> >> {code}
>> >>
>> >> The similar types of macros will be heavily used in my application and
>> >> setting it at global level will cause performance and memory issue. So,
>> I
>> >> want to set value of variable using assign.
>> >>
>> >> Please let me know if I am missing anything.
>> >> Thanks again for your time and contribution.
>> >>
>> >> - Best Regards,
>> >> Swapnil M Mane
>> >
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>>
> Thanks again for sharing your time.
> P.S. Apologies for late reply, I was out of town :-)
>
> - Best Regards,
> Swapnil M Mane
--
Thanks,
Daniel Dekany
Re: Scope of variable for <#nested> while using #import
Dear Daniel,
Thank you so much for your kind inputs.
Passing back values in nested works for me.
Please see my comments inline.
On Sat, Nov 18, 2017 at 12:50 AM, Daniel Dekany wrote:
> Friday, November 17, 2017, 3:55:22 PM, Daniel Dekany wrote:
>
> > #assign sets the variable in the current namespace. Each #include-d
>
> I wanted to write #import"-ed above... #include-d templates use the
> namespace of the includer.
>
> > template has its own namespace, plus the the topmost template has its
> > own namespace (the "main" namespace). So if you use #assign like that,
> > then in the other namespace you had to write ${widget.name}. You might
> > want to use #global instead, and then the variable is visible from
> > everywhere (unless it's shadowed by a variable of the same name in the
> > same namespace). (It's also possible to pass back a value like
> > <#nested "FreeMarker World"> and then
> > <@widget.getName ; name>${name}. Also you should write
> > a #function if you just want to get a value, not a macro, as that has
> > a return value.)
>
My bad, I used wrong example here (*getName*), actually I want multiple
values for #nested code.
like
Defining macro
<#macro linkInfo>
<#local name = "FreeMarker World"/>
<#local url = "https://freemarker.apache.org/"/>
<#nested name, url>
Using the defined macro
<#import "component://hwmapps/template/commerce/templates/Widgets.ftl" as
e/>
<@e.linkInfo ; name, url>
${name!}
So, in my case, I think, macro is needed instead of function.
>
> > See also: https://freemarker.apache.org/docs/dgui_misc_namespace.html
> >
> >
> > Friday, November 17, 2017, 1:56:03 PM, Swapnil Mane wrote:
> >
> >> Dear FreeMarker team,
> >>
> >> First I would like to thank you for creating such a nice template
> engine, I
> >> personally liked it very much :-)
> >>
> >> I need your help in an issue,
> >>
> >> While using <#nested>, the variable I defined using assign is not
> >> accessible in nested code.
> >>
> >> Here is the more details
> >>
> >> 1.) I have a macro file having Widgets.ftl
> >>
> >> {code}
> >>
> >> <#macro getName>
> >> <#assign name = "FreeMarker World"/>
> >> <#nested>
> >>
> >>
> >> {code}
> >>
> >> 2.) I have included the above file in another file using <#import>
> >>
> >> {code}
> >>
> >> <#import "Widgets.ftl" as widget>
> >> <@widget.getName>
> >> Hi ${name!}
> >>
> >>
> >> {code}
> >>
> >> Expected output - Hi FreeMarker World
> >> Actual output - Hi
> >>
> >>
> >> Here the value of 'name' variable is not setting properly if assign is
> used.
> >> But when I set it using global, everything work as expected.
> >>
> >> {code}
> >> <#global name = "FreeMarker World"/>
> >> {code}
> >>
> >> The similar types of macros will be heavily used in my application and
> >> setting it at global level will cause performance and memory issue. So,
> I
> >> want to set value of variable using assign.
> >>
> >> Please let me know if I am missing anything.
> >> Thanks again for your time and contribution.
> >>
> >> - Best Regards,
> >> Swapnil M Mane
> >
>
> --
> Thanks,
> Daniel Dekany
>
>
Thanks again for sharing your time.
P.S. Apologies for late reply, I was out of town :-)
- Best Regards,
Swapnil M Mane
Re: Attempting graduation?
Hi, I would like to change that sentence in the description: You meant to prepare the data to display in a real programming language, like issue database queries and do business calculations, and then the template displays that already prepared data. What do you think of: A general programming language is used to prepare the data, issue database queries and do business calculations. Then the Apache FreeMarker template engine displays that prepared data using templates. Cheers, — Denis. > On 21 Nov 2017, at 19:47, Sergio Fernández wrote: > > On Tue, Nov 21, 2017 at 1:06 AM, Daniel Dekany wrote: > >> Monday, November 20, 2017, 10:42:11 PM, Sergio Fernández wrote: >> >>> sorry, because I think I've created some confusion on this. Let me try to >>> explain my self, because there are to aspects on this: >>> >>> 1) From a pure ASF perspective, host the DOAP file from Git is fine. The >>> system behind projects.a.o will retrieve it and further process it. >>> >>> 2) From a broader Semantic Web perspective, ideally we should have the >> DOAP >>> file publicly available from the project web site. >>> >>> I aim for 2, that's why I played with the site build. But staying at 1 >>> should be enough. I hope now it's a bit clearer. >> >> I see, but the URL we put into projects.xml is a HTTP URL, so why not >> just add a link with that target address on the home page? That's one >> less copy of that file that can go out if sync as well. (At that point >> it doesn't even make sense anymore that it's inside "site", but >> whatever...) > > > it does for provenance reasons. But you can keep it at git, fine.
Re: Attempting graduation?
On Tue, Nov 21, 2017 at 1:06 AM, Daniel Dekany wrote: > Monday, November 20, 2017, 10:42:11 PM, Sergio Fernández wrote: > > > sorry, because I think I've created some confusion on this. Let me try to > > explain my self, because there are to aspects on this: > > > > 1) From a pure ASF perspective, host the DOAP file from Git is fine. The > > system behind projects.a.o will retrieve it and further process it. > > > > 2) From a broader Semantic Web perspective, ideally we should have the > DOAP > > file publicly available from the project web site. > > > > I aim for 2, that's why I played with the site build. But staying at 1 > > should be enough. I hope now it's a bit clearer. > > I see, but the URL we put into projects.xml is a HTTP URL, so why not > just add a link with that target address on the home page? That's one > less copy of that file that can go out if sync as well. (At that point > it doesn't even make sense anymore that it's inside "site", but > whatever...) it does for provenance reasons. But you can keep it at git, fine.
Re: Error when processing doap file https://git-wip-us.apache.org/repos/asf?p=incubator-freemarker-site.git;a=blob_plain;f=doap.rdf;hb=HEAD:
The file is valid RDF/XML file, I can warranty that. I think the infrastructure behind projects.a.o processes those files as XML, but I can't see what could be the error. On Tue, Nov 21, 2017 at 3:52 AM, sebb wrote: > You could try an online validator. > > A quick search found be this: > > https://www.xmlvalidation.com > > I'm sure there are others. > > > On 21 November 2017 at 03:48, Sergio Fernández wrote: > > Sorry, my bad. > > Fixed in de6050c6d2dfb83de20fca602533e19b26c0eade > > > > Any other details why it failed? > > > > It says "mismatched tag: line 12, column 2", but don't understand why. > > > > > > On Mon, Nov 20, 2017 at 6:28 PM, sebb wrote: > >> > >> Please can you fix the DOAP? > >> > >> Also the following entry is wrong: > >> > >> >> rdf:resource="http://people.apache.org/committers-by- > project.html#freemarker" > >> /> > >> > >> It should be > >> > >> http://incubator.apache.org"; /> > >> > >> > >> Thanks! > >> > >> > >> -- Forwarded message -- > >> From: Projects > >> Date: 21 November 2017 at 02:00 > >> Subject: Error when processing doap file > >> > >> https://git-wip-us.apache.org/repos/asf?p=incubator- > freemarker-site.git;a=blob_plain;f=doap.rdf;hb=HEAD: > >> To: Site Development > >> > >> > >> mismatched tag: line 12, column 2 > > > > >
Re: Error when processing doap file https://git-wip-us.apache.org/repos/asf?p=incubator-freemarker-site.git;a=blob_plain;f=doap.rdf;hb=HEAD:
You could try an online validator. A quick search found be this: https://www.xmlvalidation.com I'm sure there are others. On 21 November 2017 at 03:48, Sergio Fernández wrote: > Sorry, my bad. > Fixed in de6050c6d2dfb83de20fca602533e19b26c0eade > > Any other details why it failed? > > It says "mismatched tag: line 12, column 2", but don't understand why. > > > On Mon, Nov 20, 2017 at 6:28 PM, sebb wrote: >> >> Please can you fix the DOAP? >> >> Also the following entry is wrong: >> >> > rdf:resource="http://people.apache.org/committers-by-project.html#freemarker"; >> /> >> >> It should be >> >> http://incubator.apache.org"; /> >> >> >> Thanks! >> >> >> -- Forwarded message -- >> From: Projects >> Date: 21 November 2017 at 02:00 >> Subject: Error when processing doap file >> >> https://git-wip-us.apache.org/repos/asf?p=incubator-freemarker-site.git;a=blob_plain;f=doap.rdf;hb=HEAD: >> To: Site Development >> >> >> mismatched tag: line 12, column 2 > >
Re: Attempting graduation?
Monday, November 20, 2017, 10:42:11 PM, Sergio Fernández wrote: > Hi, > > sorry, because I think I've created some confusion on this. Let me try to > explain my self, because there are to aspects on this: > > 1) From a pure ASF perspective, host the DOAP file from Git is fine. The > system behind projects.a.o will retrieve it and further process it. > > 2) From a broader Semantic Web perspective, ideally we should have the DOAP > file publicly available from the project web site. > > I aim for 2, that's why I played with the site build. But staying at 1 > should be enough. I hope now it's a bit clearer. I see, but the URL we put into projects.xml is a HTTP URL, so why not just add a link with that target address on the home page? That's one less copy of that file that can go out if sync as well. (At that point it doesn't even make sense anymore that it's inside "site", but whatever...) > On Mon, Nov 20, 2017 at 5:24 AM, Daniel Dekany wrote: > >> Monday, November 20, 2017, 4:42:11 AM, Sergio Fernández wrote: >> >> > Well, it's my first interaction with the site code base, but I wouldn't >> mix >> > the doap data with the docgen sources. But I guess you can do it as you >> > prefer ;-) >> >> Indeed, it's a link to the git repo, not to the home page. I was >> confused as you have talked about build problems. Why should we do >> anything with doap.rdf in the Ant build? (You copy doap.rdf into >> build/ right now. Not sure what the intent is.) >> >> > On Sun, Nov 19, 2017 at 2:49 PM, Daniel Dekany >> wrote: >> > >> >> Ah, I have just seen your commit. You should just move doap.rtf into >> >> src/main/docgen/. No need for new Ant task. It was created on the >> >> wrong place originally... >> >> >> >> Sunday, November 19, 2017, 11:46:42 PM, Daniel Dekany wrote: >> >> >> >> > Sunday, November 19, 2017, 9:37:45 PM, Sergio Fernández wrote: >> >> > >> >> >> On Sat, Nov 18, 2017 at 7:48 PM, Daniel Dekany >> >> wrote: >> >> >>> >> >> >>> I guess it's time to add the reference to >> >> >>> https://svn.apache.org/repos/asf/comdev/projects.apache. >> >> >>> org/data/projects.xml. >> >> >>> >> >> >> >> >> >> Right. I tried to get it published to >> >> >> https://freemarker.apache.org/doap.rdf >> >> >> to add that reference, but I didn't manage to locally build the site >> due >> >> >> some dependencies' problem. I'll try again later. >> >> > >> >> > You mean a problem with incubator-freemarker-site Ant build? What was >> >> > that? >> >> > >> >> > But, you don't need to build the incubator-freemarker-site for this. >> >> > Just upload the doap.rdf to the "asf-site" branch of >> >> > incubator-freemarker-site directly. >> >> > >> >> >> In the meantime I've added the reference to git in >> >> >> http://svn.apache.org/r1815757, so it should be available at >> >> >> https://projects.apache.org/project.html?freemarker in the next >> build >> >> (2 AM >> >> >> UTC). >> >> > >> >> >> >> -- >> >> Thanks, >> >> Daniel Dekany >> >> >> >> >> >> -- >> Thanks, >> Daniel Dekany >> >> -- Thanks, Daniel Dekany
Re: Error when processing doap file https://git-wip-us.apache.org/repos/asf?p=incubator-freemarker-site.git;a=b lob_plain;f=doap.rdf;hb=HEAD:
Hi Sergio, What is saying that? As I said in my e46e2ff066afdd2464469d16b794fc7b16794c0f commit comment, and as suggested by https://projects.apache.org/create.html I then checked with https://www.w3.org/RDF/Validator/rdfval and it was OK According to the same it's still OK :) Jacques Le 21/11/2017 à 04:48, Sergio Fernández a écrit : Sorry, my bad. Fixed in de6050c6d2dfb83de20fca602533e19b26c0eade Any other details why it failed? It says "mismatched tag: line 12, column 2", but don't understand why. On Mon, Nov 20, 2017 at 6:28 PM, sebb wrote: Please can you fix the DOAP? Also the following entry is wrong: http://people.apache.org/committers-by- project.html#freemarker" /> It should be http://incubator.apache.org"; /> Thanks! -- Forwarded message -- From: Projects Date: 21 November 2017 at 02:00 Subject: Error when processing doap file https://git-wip-us.apache.org/repos/asf?p=incubator- freemarker-site.git;a=blob_plain;f=doap.rdf;hb=HEAD: To: Site Development mismatched tag: line 12, column 2
