[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scheming over a PHP replacement

From: Bruce Korb
Subject: Re: Scheming over a PHP replacement
Date: Wed, 02 Jan 2002 08:05:24 -0800

Per Bothner wrote:
> > ... you specify most of the output
> > text directly and only insert expressions here and there...
> This is a popular approach (cfr. JSP and ASP), but I'm inclined to
> think it is the wrong thing to do.  It make it easy to do a little
> bit of calculation embedded inside a mostly static document.

I'm inclined to think it a good idea:  make easy things as easy as
possible 'cuz the complex stuff isn't used as much.
Like RISC technology...

> However, it is more difficult to construct a complex document out
> of simpler pieces, except by gluing strings together.

??  Ultimately, you have to glue strings together no matter what
you do.  The output is a single-string document that gets parsed
by something else.  In this case, a browser, but any other text
doc can be emitted as easily.

> Typically
> these are string literals, which means your language now has two
> kinds of html literal text:  The outermost unquoted html, and the
> inner html, nested first inside the logic "unquote" syntax and then
> inside string quotes.

The alternative being you only have string literals?  Or, am I missing
your intent?  It seems you would be advocating adding the programming
logic necessary for managing additional embedded string literals,
instead of removing that clutter from the (hopefully minimized)
programming project.

> Worse, you are doing everything at the
> string level, which means that if you want to processes some piece
> of html though some filter function, that function has to *parse*
> the text.  This is so painful that you normally don't want to do that.

And you wouldn't normally be doing that, either.
If you do want to process the html through some
scheme code before emitting it, I would expect
it to be done within a single generation expression.
Reprocessing/reparsing text is ugly and hard.
Ultimately, though, you really do have to glue it all
together no matter how you compute the text.

> For an alternate model, I suggest people take a look at XQuery
> (

I have.  It is not clear to me that it is in keeping with
KISS for the simple tasks.  I think it burdens everything
to facilitate the hard stuff.  I facilitate the hard stuff
with this:

  <? AutoGen5 Template ?>
  <? include "html-library" ?> 
  <? html-header title = "something" ... ?>
  <? (do-arbitrarily-convoluted-work)
     convoluted-result-var ?>

has another feature:  it is working now.  :-)

> The important [XQuery] concepts are:

It looks interesting.  I'll have to look at it later.
Thanks! - Bruce

reply via email to

[Prev in Thread] Current Thread [Next in Thread]