"Daniel L. Rall" wrote:
>
> "Geir Magnusson Jr." wrote:
> >
> > [snip]
> > And there are many examples (MSFT Win32) where that is done all the
> > time, for example for threading support (beginthread()), Unicode support
> > (tchar_t), etc.
>
> Heh, referencing MFC isn't lending much support to your argument Geir.
> ;P
It has nothing to do with MFC. Its the standard Win32 API. (There are
a few computers that use it... :) MFC would have everything start with
a 'C', like CFoobar, and would be some awful member function like
BeginThreadOnAntotherMachineWithClassANetworkAddress() that would
allocate memory that you might or might not be able to figure out how to
free.
>
> > My point is simply that the language gets richer for the end user in an
> > end-user controllable fashion (they can add velocimacros) w/o making
> > the language bigger internally.
>
> The Right Way to do this is through the use of context objects--this
> provides clearer definition of the separation between templates and
> code.
And I thought there are multiple Right Ways. ("There's More than One
Way To Do It") I would love to take this offlist with someone that can
help me achieve the Right Right Way Nirvana, because I don't get why
this is bad, since we aren't allowing the designer to do any more than
they can achieve with a simple cut and paste.
To be clear, I understand the need for controlling logic and data model
to come from elsewhere, but all we are talking about would be things
rightly in the domain of the View, and I would *never* make Java objects
that return *any* markup.
If what we are talking about is a View responsibility, how can it be
justified as coming from the other domains?
>
> > > > 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.
> >
> > Surely the art major! If the art major can decide, for example, on a
> > given visual representation of something, and is able to use the
> > template engine to express that, using all sorts of things like loops,
> > including other templates, setting variables, checking variables,
> > remembering that $!foo means #if($foo) { $foo } :) , then I believe
> > they could handle defining a macro.
>
> As anyone who has done it knows, using APIs is quite a different story
> from defining reusable ones. I do not want my designers attempting to
> define APIs.
Hope you don't let them use javascript on the client then.
> > Surely someone, maybe not the core engineers, wants to prevent the evil
> > menace of cut and paste?
>
> Use of the context and #include can prevent this completely--no
> Velocimacros are needed.
Hang on. The art person sets up the template that is included. They
stuff things into the context (although someone here I remember doesn't
like even that...). How is that any different than setting up an API,
other than its incomprehensable to a casual reader?
Anyway, I won't belabor this. If anyone wants to help a poor pilgrim on
his road towards the Right Way(tm), I am eager for the help.
geir
--
Geir Magnusson Jr.
[EMAIL PROTECTED]
