"Geir Magnusson Jr." wrote:
>
> "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... :)
Have you ever looked into the bowels of MFC, Geir?
> 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.
hehehehe
> > 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.
There are multiple Right Ways, but generally only one given a specific
set of tools and goals. One of my goals for Velocity is to prevent the
designers and artists from having the ability to create programmatic
interfaces. It's not their job.
> 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.
+1, no one suggested that they should.
> If what we are talking about is a View responsibility, how can it be
> justified as coming from the other domains?
The View uses the utility objects placed in the context to get its job
done.
> > 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.
JavaScript is a complete abombination. I limit its use to setting form
field focus, which some browsers unfortunately don't do by default.
> > > 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?
Heh. The artist doesn't do any stuffing--that's the application
developer's job. The artist can request dynamic values from the
programmer, which is indeed a bit of interface definition. But that's
the extent of it--they can do no more.
> 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.
I totally understand your comments on Velocimacros--they're great if
you're both programmer and designer. But the product they produce isn't
maintainable by a pure artist/designer, which is who you really want
maintaining your UI. Velocimacro-style development just doesn't work in
practice. Don't think we haven't already been down that road. ;)
I hope this helps your understanding of how we see things.
--
Daniel Rall <[EMAIL PROTECTED]>
