freemarker-user Mailing List for FreeMarker template engine (Page 240)
Generates text that depends on changing data (like dynamic HTML).
Brought to you by:
revusky
This list is closed, nobody may subscribe to it.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(6) |
Aug
(3) |
Sep
(26) |
Oct
(18) |
Nov
(34) |
Dec
(21) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(103) |
Feb
(82) |
Mar
(116) |
Apr
(36) |
May
(56) |
Jun
(130) |
Jul
(78) |
Aug
(91) |
Sep
(11) |
Oct
(60) |
Nov
(21) |
Dec
(21) |
2004 |
Jan
(29) |
Feb
(19) |
Mar
(87) |
Apr
(30) |
May
(6) |
Jun
(32) |
Jul
(2) |
Aug
(8) |
Sep
(26) |
Oct
(36) |
Nov
(40) |
Dec
(29) |
2005 |
Jan
(65) |
Feb
(43) |
Mar
(44) |
Apr
(42) |
May
(89) |
Jun
(90) |
Jul
(50) |
Aug
(49) |
Sep
(62) |
Oct
(60) |
Nov
(48) |
Dec
(33) |
2006 |
Jan
(48) |
Feb
(104) |
Mar
(94) |
Apr
(106) |
May
(139) |
Jun
(105) |
Jul
(84) |
Aug
(56) |
Sep
(46) |
Oct
(93) |
Nov
(21) |
Dec
(14) |
2007 |
Jan
(22) |
Feb
(35) |
Mar
(68) |
Apr
(45) |
May
(125) |
Jun
(84) |
Jul
(57) |
Aug
(23) |
Sep
(16) |
Oct
(48) |
Nov
(39) |
Dec
(32) |
2008 |
Jan
(24) |
Feb
(55) |
Mar
(61) |
Apr
(128) |
May
(125) |
Jun
(91) |
Jul
(53) |
Aug
(35) |
Sep
(30) |
Oct
(66) |
Nov
(56) |
Dec
(20) |
2009 |
Jan
(27) |
Feb
(62) |
Mar
(27) |
Apr
(18) |
May
(58) |
Jun
(54) |
Jul
(17) |
Aug
(34) |
Sep
(32) |
Oct
(68) |
Nov
(31) |
Dec
(55) |
2010 |
Jan
(25) |
Feb
(44) |
Mar
(53) |
Apr
(38) |
May
(42) |
Jun
(39) |
Jul
(40) |
Aug
(27) |
Sep
(32) |
Oct
|
Nov
(12) |
Dec
(30) |
2011 |
Jan
(48) |
Feb
(25) |
Mar
(21) |
Apr
(23) |
May
(47) |
Jun
(55) |
Jul
(40) |
Aug
(48) |
Sep
(33) |
Oct
(13) |
Nov
(19) |
Dec
(12) |
2012 |
Jan
(4) |
Feb
(19) |
Mar
(20) |
Apr
(49) |
May
(18) |
Jun
(17) |
Jul
(19) |
Aug
(12) |
Sep
(3) |
Oct
(24) |
Nov
(6) |
Dec
(9) |
2013 |
Jan
(4) |
Feb
(14) |
Mar
(35) |
Apr
(20) |
May
(21) |
Jun
(6) |
Jul
(35) |
Aug
(12) |
Sep
(11) |
Oct
(7) |
Nov
(2) |
Dec
(6) |
2014 |
Jan
(4) |
Feb
(3) |
Mar
(6) |
Apr
(5) |
May
(4) |
Jun
(6) |
Jul
(7) |
Aug
(1) |
Sep
(11) |
Oct
(26) |
Nov
(3) |
Dec
(11) |
2015 |
Jan
(1) |
Feb
(14) |
Mar
(12) |
Apr
(2) |
May
(7) |
Jun
(12) |
Jul
(14) |
Aug
(3) |
Sep
(10) |
Oct
(1) |
Nov
(8) |
Dec
(4) |
2016 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(6) |
May
(1) |
Jun
(10) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Jonathan R. <jre...@te...> - 2002-07-01 19:30:54
|
On Monday 01 July 2002 09:18 am, you wrote: > AFAIK, no one besides us (FM developers) actually uses > TemplateTransformModel, so I guess it's safe to tweak it in place. Well, I would be temped just to replace the older TemplateTransformModel API by the newer one. The truth is that TemplateFilterModel is not really a new feature. It's the same old feature -- but implemented correctly! :-) Still, it seems politically incorrect to drop the older API without first deprecating it for a few releases. OTOH, as I pointed out, there is a bit of boilerplate code you can add to change the older API into the newer one. What do people think? Cheers, Jonathan > > Attila. > > ----- Original Message ----- > From: "Jonathan Revusky" <jre...@te...> > To: <fre...@li...> > Sent: 2002. június 28. 20:58 > Subject: Re: [Freemarker-devel] Environment for method and transform data > objects > > > but I am actually wondering whether it wouldn't be better to just leave > > that > > > API as it was and introduce something new that is more powerful -- > > something > > > like the 4 methods above. > > > > Cheers, > > > > Jonathan > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Freemarker-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemarker-devel |
From: Jonathan R. <jre...@te...> - 2002-06-30 17:03:27
|
On Sunday 30 June 2002 11:56 am, you wrote: > Friday, June 28, 2002, 5:39:05 PM, Jonathan Revusky wrote: > > BTW, there was something else I did yesterday which I didn't mention. A > > function can now be used the same way as a method. Or to use a simple > > example: > > > > <call foo(bar)> > > > > produces the same output as: > > > > <assign foobar = foo(bar)>${foobar} > > > > which is the same as: > > > > <assign alias=foo><call alias(bar)> > > > > This also means that functions simply exist in the same namespace as > > other variables. > > [snip] > > No, it's IMO really not good. This is confusing, also it may will have > problematic consequences in the future. > > What's confusing here is that you mix functions and data model > (functions and method data objects). Well, this, in some programming languages, is considered a selling point -- the idea that a function (or block of code, i.e. closure) is a first-class object like any other object. And you can pass it around and do things with it. So it's not so obviously bad. (Not that it is so obviously good either, but one could debate both sides of the argument legitimately....) In any case, the way FreeMarker deals with functions in includes (and this predates my involvement) is to stick them in the data model. So the possibility of a function hiding a top-level variable already existed. > We really should not do that, as > it makes dirty the whole template + data model = output idea. Also it > is confusing in itself that something is not part of the data model, Well, we have transformations (or filters) that are not themselves data per se. So, by this reasoning, the current situation is already "dirty". > but in some situations it seems that it is part for that. And, it > bring yet another hiding complication (it hides data model), yet > another rule to remember. Well, one possibility would be to extend the "strict syntax" so that it gives functions a special naming pattern. So, check out this idea: how about if, in the strict syntax, all functions necessarily end in '!' ? <#call foo!(bar) /> Since foo! is not a valid identifier for variables, then there is no ambiguity in terms of assignments. <#assign myFunc! = foo!> <#call foobar!(foo!)> (Invokes function foobar! with the function foo! as a parameter.) This is a new idea. I'm not sure about it... The other idea that just occurs to me is that the #call in <#call foo!(bar)> is superfluous. In <foo!(bar)> the exclamation mark already identifies foo as a function. (And note that foo! is not a valid markup tag, right?) Of course, the exclamation mark in <call foo!(bar)> is also superfluous... > > As of the future problems, I think we should extends the capabilities > of functions (BTW, can we rename them to macros at least?). So we may > will support body, named parameters, etc. IMO the goal should be that > the syntax of function calls is similar to XML (or maybe HTML) syntax. > And then, the whole above idea becomes problematic. So IMO we should > extend functions first, and only then we should deal with the above > ideas. The named parameter idea seems good, since it would make thing thing look more like XML. > > But, if I can do a quick recommendation, we should do rather something > like this, and don't confuse method data objects and functions: > > - How to pass function to another function? > Pass a string, and then do <call #name=theString ...> > - How to store the output of a function in a variable? > A more universal solution: > <capture foo> > do anything here... > </capture> > And we have the output stored in the foo variable. Hmm, that's a pretty reasonable idea. Worthy of thought definitely... :-) I think we need a moratorium on new features for a while though. The code is in a very clean state, so I can implement almost anything very easily. It really gets too tempting... ;-) Cheers, Jonathan > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Freemarker-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemarker-devel |
From: Jonathan R. <jre...@te...> - 2002-06-30 02:02:41
|
Folks, There is a bleeding edge .jar file available from the usual place. http://revusky.com/dist/freemarker.jar The generated javadoc is at: http://revusky.com/fmdocs/ This has all the latest stuff, the TemplateFilterModel is implemented, local variables in loops and functions. Enjoy, Jonathan |
From: Jonathan R. <jre...@te...> - 2002-06-29 21:00:29
|
I recently implemented local variables in function bodies. I am wondering whether we should introduce local variables for loops as well. <foreach item in foo> <local var = 12> .... </foreach> It would be quite easy to have the above working as well. And in general, a local variable would be defined for the most limited context available. <function foo()> <local something = 1234> <foreach item in bar> <foreach thing in baz> <local var = "boo"> ... </foreach> ... </foreach> </function> A related question is what to do with <assign> Currently, I have it do a local assignment if you are in a function, and a global assignment if you are outside a function. Is that the correct behavior, or maybe for backward compatibility, <assign...> should mean the same thing as <global...> ? I'm interested whatever feedback on this I can get. Cheers, Jonathan |