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

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.

>
>>> 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.)

> 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?

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.

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?


> 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? Using | is a bit tricky because it is an
operator in FTL.

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
>
>
> -------------------------------------------------------------------------
> 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
> _______________________________________________
> FreeMarker-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>

-------------------------------------------------------------------------
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