"Geir Magnusson Jr." wrote:
>
> "Daniel L. Rall" wrote:
> >
> > Your macro would be called as a directive because of the '#' in front of
> > it.
>
> Yes, in the syntax from the view of the designer, I guess it would be.
> On the implementation side, a preprocessing step would be included which
> expands the macros out before being actually processed, which are
> written using the 'regular' directives of the language, so the piece
> that processes the directives wouldn't see anything new.
>
> <aside>
> My language formalism is weak : is it true that in the following C
> program
>
> #define FOO(x) x=x*2
>
> main()
> {
> int x = 1;
>
> if (x)
> FOO(x);
> }
>
> both 'if' and 'FOO' are considered directives? If not, why would they
> both be in my example above?
>
> </aside>
>From a C programmer's view, 'if' is a flow control statement, and 'FOO'
is a macro.
> > Unfortunately, I haven't seen this work all that well in practice. The
> > art major that you just hired straight out of college should focus on
> > the look and feel of your web site, not on climbing the learning curve
> > of how to call Velocimacros. I would prefer not to reinvent PHP or ASP
> > style development, and adding Velocimacros would allow this, regardless
> > of original intent and usefullness to the uber-designer.
>
> So the art major then sets up look and feel thing, and that is captured
> and formalized into Velocimacros, so his/her art minions can code the
> content templates. Then, when fashion changes, you can modify the
> velocimacros for a wholesale change.
Who captures and formalizes it? Surely not the art major. I don't want
to have anything to do with that part of the process, I have way too
much work to do on various core engineering activities. Let's stick
with the KISS philosophy.
> So the art major does what then to address the issue in the current
> implementation?
[snip]
> I guess if this doesn't happen, one can always write a template
> preprocessor to do exactly this (expand macros into velocicode) but that
> seems to be one of the purposes of a template engine anyway.
The context is meant to supply the tools to do this sort of thing.
As an aside, I would very much like to have the ability to configure the
*default* behavior for a null evaluation, for when the evaluation is not
handled by some other doodad (like flow control or the suggested context
tools). This seems to belong more in a configuration file, however,
than in the templates themselves.
--
Daniel Rall <[EMAIL PROTECTED]>
