[Prev][Next][Index][Thread]
Re: Some inquiries about Dylan tutorials and documentation
Bruce Hoult wrote:
>
> I don't see any reason to *need* an interpreted language for this sort of
> thing. Sure, it's often more convenient to embed bits of code in an html
> document than to embed bits of html in a program, but all tat means is
> that you should use some sort of pre-processor tool that can extract those
> bits of code and make a pogram from them and compile it.
Heh.
And you expect the HTML/Java "web programmer" crowd to grasp this??? The
idea that no HTML should ever be embedded in code hidden away from the
non-programmers seems to be considered a sophisticated concept here.
Ugh. And don't even get me started on JavaScript and similar approaches
where HTML contains a tag that contains a script that "prints" HTML out
as a side effect. Could one conceive of an uglier and more confusing way
to express a dynamic page?
As for your idea specifically: web sites need to be updated frequently
and on the fly. So to use a front end that processes and compiles a
template to a program basically requires either: that the result be a
dynamically loadable and replaceable library and that the "server",
whatever that is, can load it while running; or that the template become
a standalone executable called by the server for each invocation, which
can involve a performance hit from the process startup and shutdown; or
that the template become a standalone program that persists between
invocations and is called via some IPC mechanism.
I'm not arguing that it's a bad idea. It's a great idea. But
implementing it in practice requires a level of sophistication (and
actual programming work) that is generally lacking in web tools. Which,
when you think about it, is probably an argument FOR doing it this way
with Dylan ;-)
An interpreter built into the server that tokenizes or parses the
templates, caches the results, and "executes" the partially preprocessed
templates for each invocation is a pretty good compromise. The
flexibility is definitely there; the HTML is kept out of the server code
and in the documents where it belongs; and performance is pretty good.
Of course, in my case, because of limitations of the tool it was the
ONLY way to keep the HTML where it belonged and get decent performance.
So I can't say that I made the choice based on any deep insight into the
tradeoffs; I just did what I had to!
So... If I actually get around to doing web development using Dylan...
I'll have to try the preprocessor/compile approach. Of course that would
HAVE to work with GD, since I wouldn't want users to have to buy FO
Dylan to compile their templates! (And I would want the cross-platform
aspect as well.)
References: