At 13:22 19-09-98 +0100, David Meadows wrote:
>Axiom 1: Scripts (client-side or server-side) are 
>used to modify a document dynamically in 
>response to user requests.

They _can_ be used to modify a document. but they can also be used for many
other things, including creating documents, creating graphics and
multimedia, and many other activities. They can be used dynamically (on a
per page-request basis), dynamically (on a per time-interval basis), or to
produce static pages and other files.

>Axiom 2: Server-side scripts are preferable to 
>client-side scripts in all cases where you do 
>not have total control
over the client's
>browsing environment.

Change "all cases" to "many cases" or "typically" and we'll agree.

>JScript or VBScript running on the server can access [...]

You might want to include PerlScript in your list as well, as it shares
these capabilities, limited only by limitations of Microsoft's ASP
technologies.


>I am not fully conversant with Perl, but I 
>don't imagine it can do anything that 
>server-side ActiveX Scripting cannot also do.

I've no disagreement with this statement. Beyond your imagination, there
are many areas where perl can do many things, beyond the scope and
constraints of ActiveX Scripting [as well as that it can work within those
constraints].

One of the things which perl allows is for one to use simple methodologies
for simple problems, and more complex methodologies for more complex
problems. ActiveX Scripting, by contrast, imposes a complex technology on
all problems.

>I believe that a document served by a Perl
>script is 100% generated by the Perl script. 

If one chooses to do things that way, sure. If one doesn't, it sure doesn't. 

I've a single perl script, for example, which builds pages to assist in
accessing a collection of  many thousand digital camera images. It can be
used (and is) as a CGI script to generate pages using the latest catalog
files. It can be (and is) used on both UNIX and NT/IIS Web servers. It can
also be used as a batch script (via a batch file) to build the many
hundreds of HTML files which accompany a CD-ROM of the images. I can easily
(and do) build multiple CD-ROMs, each with very different user interface
and presentation, just by having different page templates.

>So to modify any part of the page, you have 
>to re-write the Perl script (surely more arduous 
>than editing the HTML page?) 

Surely you jest. What you describe is often done for quick-and dirty tasks
with perl... but then again since it is so easy to do so much, one often
does. Also keep in mind that such a technique is significantly more
efficient than the alternative you suggest. [0]

Since the generalization of using a template file is only a handful of
lines of code, it is often easier to do so than coding all the lines of an
HTML file.

>I stand ready to be corrected on this, because 
>I really don't know Perl well enough and may be
>misunderstanding how it works.

>Oh yeah... I was gong to advance a hypothesis... uh...
>
>    "Server-side ActiveX scripting is the best 
>way to dynamically create HTML documents"

Quite possibly this is true for you own situation. But it depends a great
deal on the definition of "best" which works for you. I would suggest that
there are others who share similar expectations, and many who have quite
different requirements and expectations.

Quite possibly ~snake oil~ is the only "best way" to do any and all things,
when advocated as the end-all and do-all solution, without regard for the
problem at hand.

/Harold

ps. Perl is many things, a scripting and programming language, as well as a
way of thinking. Perl works within ActiveX (PerlScript), within CGI, at the
command shell level, among others. Hence it is much more, and no more, than
those who are making use of it.

pps. Perl is a great tool, for many things. But it is certainly not the
only tool. Besides, heck, if the only tool one has is a hammer, then the
whole world soon becomes a nail. <g>
=========================
[0] There really are sites which are seriously concerned with (and actually
do provide) timely response to a huge number of queries, with a quite
modest amount of hardware. Unlike Microsoft (who profits more when a site
needs more computers, sometimes profiting geometrically), most site
administrators have the goal of keeping both hardware and software
expenditures to a practical minimum. 

[As a frequent user of the Web, I very much appreciate the many sites who
routinely provide quality performance, vastly in excess of that which I've
experienced with NT IIS sites such as *.microsoft.com and *.msn.com... the
proverbial proof of the pudding being most certainly in the tasting.]

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Harold A. Driscoll                       mailto:harold(at)driscoll.chi.il.us
#include <std/disclaimer>      http://homepage.interaccess.com/~driscoll/

• Web Designer Courses
• Off the Shelf Training Courses

HWG hwg-theory mailing list archives, maintained by Webmasters @ IWA