Re: [FM3] Should localized template lookup be off by default?

[Siegfried Goeschl]

Hi folks,

sorry to skip in as FM rookie :-)

IMHO both approaches (opt-in & opt-out) are valid but I personally lean towards 
opt-out

* The newbie (and casual user) is delighted if a useful feature works out of 
the box
* Changing the existing behaviour is an annoying (and potentially breaking) 
change for existing users
* Assuming that the caching works the IO is minimal even for cache misses
* Assuming that the little IO becomes relevant those user will be heavy users 
anyway

Thanks in advance,

Siegfried Goeschl


> On 14 Jun 2017, at 11:12, Daniel Dekany <ddek...@apache.org> wrote:
> 
> Tuesday, June 13, 2017, 2:49:17 PM, brede...@me.com wrote:
> 
>> ‎-1
>> 
>> I think that is one place where feature by default is better than 
>> performance by default. 
> 
> OK, but why?
> 
> The reason I prefer opt-in approach (as opposed to opt-out) here is
> that you won't use this feature unless you are aware of its existence.
> But if you are aware of its existence, and you want to use it too,
> then certainly you will see that you have to turn it on. For the
> others, who are the vast majority of users, why waste resources
> (especially I/O) on something they will not use? For low level
> libraries things like that mater, because you can't anticipate the use
> cases. In some applications they may need to keep the
> templateUpdateDelay low, and have many templates, so cache misses are
> frequent.
> 
>> Are the missing files cached?
> 
> Yes, the fact that a file is missing is cached, for
> cfg.templateUpdateDelay duration.
> 
>> Cheers,
>> 
>> -- Denis.
>>   Original Message  
>> From: Daniel Dekany
>> Sent: Tuesday, 13 June 2017 13:19
>> To: dev@freemarker.incubator.apache.org
>> Reply To: dev@freemarker.incubator.apache.org
>> Subject: [FM3] Should localized template lookup be off by deault?
>> 
>> In FM2 the localizedLookup configuration setting defaults to true, so
>> by default if you issue cfg.getTemplate("foo.ftl") and cfg.locale is
>> en_US, then FM will look for foo_en_US.ftl, then foo_en.ftl, then
>> foo.ftl. I think most users don't use localized lookup, and they don't
>> realize that this is happening, while this means extra I/O.
>> 
>> I propose that in FM3 we change the default of this setting to false.
>> 
> 
> -- 
> Thanks,
> Daniel Dekany
> 

Re: Request For Comment - freemarker-cli

[Siegfried Goeschl]

HI folks,

I will migrate the Groovy script to Java-only code on GitHub in the next few 
weeks - I guess my colleagues will be happy to have JDK-only dependency :-)

When I’m finished you can still decide if you would like to setup links to 
(more or less) useful contributions or consider a code contribution :-)

Thanks in advance,

Siegfried Goeschl


> On 8 Mar 2017, at 08:00, Daniel Dekany <ddek...@freemail.hu> wrote:
> 
> Note that freemarker-online tries to avoid taking any serious
> workload. Surely it can be easily DoS-ed to death, but it tries not to
> be useful for doing actual work (like you can't upload data file to
> transform), so at least well behaving users won't kill it. It's for
> trying the template language.
> 
> Something that users can download and run themselves is an entirely
> different story of course. I'm not sure if there would be a
> significant overlap with freemarker-online though, given how little
> freemarker-online can do, by design. Well, unless the standalone tool
> also have a browser interface (as opposed to SWT or Swing), they may
> want to share something like a better FTL editor for example. Also, a
> GUI and a CLI tool can surely share a lot of course.
> 
> 
> Wednesday, March 8, 2017, 7:03:13 AM, Woonsan Ko wrote:
> 
>> Hi Siegfried,
>> 
>> Thanks for sharing your work!
>> In my view, the main question is around how we can position the tool
>> like what you implemented. In other words, would it belong to report
>> generation area, simple data conversion tool area, or generic
>> freemarker execution tool (or CLI) area?
>> In my gut feeling, it could be best if it is possible to merge the
>> freemarker-online-tester tool and your work together, and position it
>> as a more generic freemarker CLI (and GUI support later?) tool. So
>> people may download the tool to execute/test ftl sources locally with
>> data, or we can deploy the tool as online service
>> (freemarker-online-tester). Perhaps in the future, the CLI tool may
>> support GUI, CLI, and web-online modes for users' convenience.
>> So, if this vision is okay to the community, it might be worth
>> combining both efforts into one as a new product (and as a subproject
>> of freemarker).
>> What do others think?
>> 
>> Regards,
>> 
>> Woonsan
>> 
>> 
>> On Mon, Mar 6, 2017 at 10:46 AM, Siegfried Goeschl
>> <siegfried.goes...@gmail.com> wrote:
>>> Hi Daniel,
>>> 
>>> as far as I’m concerned
>>> 
>>> * At the end of the day the committers & PMC decide what become part of the 
>>> project
>>>* The same is said for adding links to external projects :-)
>>> * The users do care about solving a problem a hand
>>>* They don’t care a millisecond if it is part of an ecosystem or not 
>>> as long as they can find the tools they need and get their stuff done
>>>* An alive-and-kicking ecosystem will result in new users of 
>>> FreeMarker
>>>* They might not even care if there is Velocity or FreeMarker under 
>>> the hood :-)
>>> * I’m aware of http://freemarker-online.kenshoo.com 
>>> <http://freemarker-online.kenshoo.com/> and I think this is a brilliant idea
>>> 
>>> Thanks in advance,
>>> 
>>> Siegfried Goeschl
>>> 
>>> 
>>> 
>>>> On 6 Mar 2017, at 16:24, Daniel Dekany <ddek...@freemail.hu> wrote:
>>>> 
>>>> Regarding if it's an useful contribution to the project. Currently,
>>>> the Apache FreeMarker (incubating) project is only the engine itself.
>>>> So unless we widen the scope of the project, while it certainly helps
>>>> with the popularity/usefulness of the FreeMarker project, it's not a
>>>> direct contribution to it.
>>>> 
>>>> Some may point out that the project already have multiple "products",
>>>> all in its own repository (but still under the umbrella of the Apache
>>>> FreeMarker project):
>>>> 
>>>> - freemarker: The engine itself, freemarker.jar. This is the only thing
>>>> has releases. The others are just dependencies.
>>>> 
>>>> - freemarker-docgen: Transforms XDocBook to HTML. The reason it's here
>>>> is that both our homepage and the Manual are generated with this.
>>>> 
>>>> - freemarker-site: The content of the homepage
>>>> 
>>>> - Recently we started working on bringing over the small project
>>>> behind http://freemarker-online.kenshoo.com/. So it's 

Re: Request For Comment - freemarker-cli

[Siegfried Goeschl]

Hi Denis,

a few thoughts along the line

* all of the mentioned dependencies are ASL 2.0 so in terms of licences that is 
as safe as it gets
* personally I would have a hard time NOT use Apache Commons CSV :-)

Thanks in advance,

Siegfried Goeschl


> On 6 Mar 2017, at 12:52, brede...@me.com wrote:
> 
> Thanks Siegfried, looks good. 
> 
> It has dependency on org.jayway.jsonpath, org.apache.poi and 
> org.apache.commons, need to think how to handle that (I may select a 
> different csv parser in fact).
> 
> Regards,
> 
> -- Denis.
>   Original Message  
> From: Siegfried Goeschl
> Sent: Monday, 6 March 2017 11:07
> To: dev@freemarker.incubator.apache.org
> Reply To: dev@freemarker.incubator.apache.org
> Subject: Request For Comment - freemarker-cli
> 
> Hi folks,
> 
> I'm playing around with Template Engines for a couple of years and over 
> Christmas I moved some of my code from Velocity for FreeMarker.
> 
> One piece of code which could be useful to the public is 
> https://github.com/sgoeschl/freemarker-cli 
> <https://github.com/sgoeschl/freemarker-cli>
> 
> * Don’t now if I already re-invented the wheel :-)
> * Please note that this is my first contact with Apache FreeMarker
> * I would like to ditch Groovy and migrate to a stand-alone Java application
> * It is already under ASL-2.0
> 
> So the question is - could this be a useful contribution to the project?! As 
> far as I know open source is not oneway only :-)
> 
> Thanks in advance,
> 
> Siegfried Goeschl
>