Re: [Freemarker-devel] interested in feedback with new template engine

Monday, June 30, 2008, 1:53:20 PM, Jonathan Revusky wrote:

> On Mon, Jun 30, 2008 at 12:41 PM, Daniel Dekany <[email protected]> wrote:
>> Monday, June 30, 2008, 11:12:55 AM, Attila Szegedi wrote:
>>
>>> On Jun 29, 2008, at 11:32 PM, Joe Hudson wrote:
>>>
>>>> [sorry if this appears more than once - I sent it from the wrong
>>>> account previously and canceled the message so I don't think it will]
>>>>
>>>> Hello everyone,
>>>>
>>>> I have created a new template engine to address some missing
>>>> functionality that I have wanted in FreeMarker for a long time.  I
>>>> would really appreciate feedback from anyone that would like to kick
>>>> the tires.  It is called ZipScript and can be found at http://www.zipscript.org
>>>>  (which will take you to the googlecode project page).
>>>
>>> Did you start this from scratch, or did you fork FreeMarker?
>>
>> (Scratch AFAIK...)
>
> Yes, completely, it seems. A large amount of work. I would have
> thought it would be far less work to add the needed functionality to
> FreeMarker.

(Or not. Forking and understanding other people's code can be quite a
big, and most importantly, frustrating and unexciting work.)

>>>> Also, I am not terribly good at writing friendly documentation and
>>>> would appreciate anyone that would like to participate in the growth
>>>> of this project with me especially in the docs area...
>>>>
>>>> Some of the features that I have address are:
>>>>
>>>> - can define macro parameters as nested components (which gives you
>>>> the ability to create complex UI components)
>>>
>>> I'm not sure I understand what does this mean. For FM 2.4, we do have
>>> curried macros though, if that's what you had in mind.
>>
>> Well it was discussed a lot earlier, although certainly only me and
>> Joe was responsive in that thread. I count this thing among those that
>> the two main FM guys (or of three) don't get for unexplained reasons,
>> like #nested earlier.
>
> I guess I never felt that there was a clear proposal that I could just
> sit down and implement. (Though maybe there was and I wasn't paying
> attention.)

OK, but I felt that problem itself wasn't understood/respected either.
Whatever...

>> Anyway, here you will find an example:
>>
>> http://code.google.com/p/zipscript/wiki/FreemarkerComparison
>>
>
> The syntax implemented seems rather odd. What distinguishes the inner
> parameter or component from simply another macro invocation?

When I last saw it, if a parameter name matches the macro name in a
nested macro invocation, it will be treated as a parameter, rather
than a regular macro call. However this only worked when the said
nested macro invocation is in the nested content *lexically*. That was
one of the things that I didn't liked. Anyway, Joe, you really should
write a Wiki page about this, rather than re-explaining it to everyone
in e-mail.

> At some point earlier, I had an implementation of something similar,
> but with a new directive called #fragment and then you put a fragment
> in your macro invocation and you optionally could invoke #nested with
> a fragment="fragmentname" specifier and it would do the nested body of
> the fragment instead.

That's quite much like in JSP, and it's also that crippled. Like you
can add fragments conditionally, or in a loop, etc. Also, these
fragments should have parameters, like (just a dummy example)
<#fragment 'chapter' title=theTitle>.

> I later pulled it out because I was redoing so many things that I
> figured I'd put this back in later (or not) after the cleanup.
>
> I am seeing some amount of need for this because I am working on a new
> project called KawaDD, a fork of JavaCC (I had to fork because the
> people there were impossible) and I want to encapsulate eventually
> some language constructs and then you start realizing that something
> like try-catch-finally is actually a try block plus one or more catch
> blocks plus a finally block, so multiple inner blocks to the macro
> seems necessary to capture it cleanly.
>
> Now that you've had even more time to think about it, how would you
> like to see it work?

In my (unimplemented but clearly doable) solution the fragments are
regular macro calls (of not-entiery-regular macros), that when
executed, just a add bean-like objects to a tree structure. The
bean-like object contains an anonymous macro that encapsulates the
nested content of the fragment, also it contains the actual parameter
values, and also it contains a reference to the macro that created the
object. The mentioned tree structure belongs to the "parent" macro
invocation (using parent-children communication -- a more advanced one
than FM 2.4's). And it's a tree, not just a list, because "fragments"
may be nested into each other. So, to access the nested "fragments" in
the parent, you will have to call #nested. As I said, when the
"fragment" calls are executed, they will not execute their nested
content, just define an anonymous macro and add the said bean-like
object to that tree. So after #nested, the parent macro can explore
this tree freely, examine the parameters, do searches, etc, also it
can "execute" the beans, i.e., call the anonymous macros.

>> Besides, I disagree the *way* Joe has addressed the issue, unless it
>> was changed since then when I last saw it. (Joe, did it changed, did
>> you addressed the discussed "problems"?) But surely it addresses the
>> issue at least. (And yeah, as you could find out without saying, :) in
>> my vapor war I addressed it too, differently. That's why I have the
>> ground to disagree, of course.)
>>
>>>> - added a formatting character '|' so you can do stuff like $
>>>> {myDate|"MMM dd, yyyy"} or ${myDate|short}
>>>
>>> Did you find writing ${myDate?string("MMM dd,yyyy")} in FreeMarker too
>>> verbose?
>>
>> Note that I do, for ages. (This you may already know, since I have
>> proposed the nearly same thing for several occasions here. It even
>> used "|".)
>
> Why don't we just use the semicolon as in the (now deprecated)
> numerical interpolation?

Because ";" implies weak priority. I mean, out of convention it does.
But, after all, maybe we want weak priority for this...

> Using | is a bit tricky because it is an operator in FTL.

Oh, it's an alternative to "||"? /-: I hate these "there is more ways
doing it" things.

> In any case, this is quite trivial to add. I guess we should.
>
> JR
>
>>
>>>> - added boolean and object evaluators so you can get more than just
>>>> merge a template with an object model to get the string results
>>>
>>> I see - so you're sort-of moving toward a generic programming language
>>> here, aren't you, by being able to return non-text values from
>>> templates?
>>
>> It never hurts... But what is a template? An expression that evaluates
>> to a string (or XML DOM).
>>
>>> Attila.
>>
>> --
>> Best regards,
>>  Daniel Dekany

-- 
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php