On Wed, 2002-12-18 at 18:11, Chris Nokleberg wrote:
> On Wed, Dec 18, 2002 at 03:27:41PM +0100, Jonathan Revusky wrote:
> > It seems to me that we would then need an SGML minimized end-tag, like:
> >
> > </@>
> >
> > >
> > > Therefore, I'd strongly prefer if <@mylib.mytag> could be written directly
> > > to improve the readability of templates that use JSP taglibs.
> >
> > It's more flexible, I suppose, and terser. OTOH, the readability
> > argument strikes me as tenuous. It is probably more readable in general
> > to write the above in two steps.
> >
> > <assign mytransform = (some complex expression)>
> > <@mytransform>
> > ...
> > </@mytransform>
> >
> > As opposed to:
> >
> > <@(some complex expression)>
> > ...
> > </@>
>
> I strongly support something complex expressions after <@, coupled with
> something like </@>. The main reason is that <assign> works globally,
> and if you are writing independent modules of macros, it is not safe to
> use the root hash as a temporary variable storage space. At least, not
> unless you have strict naming conventions.
>
> If there was some concept of "scope", you could use local as a lexical
> variable:
>
> <#scope>
> <#local mytransform = (some complex expression)>
> <@mytransform>
> ...
> </@mytransform>
> </#scope>
Well, we have this within macro bodies. I mean, there isn't that much
difference between the above and:
<#macro mymacro>
<#local mytransform = (some complex expression)>
<@mytransform>
...
</@mytransform>
</#macro>
followed by:
<@mymacro/>
I suppose it's a bit clumsy really.
On another tack, it has occurred to me that the equivalent of the "with"
in pascal could be useful.
<#with foo.bar>
....
<@baz>
....
</@baz>
</#with>
And then (within the with block) the baz reference would resolve to
foo.bar.baz. Assuming foo.bar.baz exists. Otherwise it would revert to
the global baz and then failing that, would just throw an exception of
course...
That would actually be pretty easy to implement, I think. And it might
mesh pretty well with the JSP taglib stuff...
>
> But this is getting too much like a programming language, I think.
Yeah, that is the consideration that holds me back from this kind of
thing. Though, actually, a lot of real programming languages don't solve
the namespace issues particularly well. That was always one thing that
java has had in its favor. It solves the namespace issue from the start
and quite simply and cleanly.
OTOH, I don't know how much of a problem the namespace stuff is in
practice in our application domain. How big a body of FTL code are most
people maintaining? Is it of a scale of complexity where there is such a
need for namespaces?
And, after all, the lack of any real solution for namespaces never
seemed to prevent people from writing huge unix shell-scripts.... :-(
(The above is just me musing out loud... don't jump on that... :-))
And OTOH, newer script languages that are gaining popularity, like
python and ruby, definitely have solved the namespace issue from day
one... but those are still real programming languages OTOH...
Well, probably it's desirable if it can be done in a completely
unobtrusive way, so that people who find that their codebase is reaching
a complexity level where they need it, can grow into it, but people who
don't need it remain blissfully unaware....
Cheers,
Jonathan
>
> -Chris
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
> Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
> MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty.
> T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
> _______________________________________________
> FreeMarker-devel mailing list
> FreeMarker-devel@...
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>
|