[going OT] Re: How To Dynamic Web Rendering?

Nick Sabalausky a at a.a
Thu May 12 15:56:36 PDT 2011


"Adam D. Ruppe" <destructionator at gmail.com> wrote in message 
news:iqhkdn$1co1$1 at digitalmars.com...
>> Ugh. Apperently, too much Flash/PHP/HTML/etc has rotted my mind...
>
> Speaking of brain rot, the first version of my cgi.d actually aimed
> to mimic PHP! Some stupid part of me actually started to *like* the
> superglobals for a while...
>

Heh. Well they are at least convenient. I'm sure that's probably why PHP did 
it in the first place.

> It had a static module constructor that built the arrays, and gave
> them global names like PHP does:
>
> import cgi;
>
> void main() {
>     auto my_var = _POST["my_var"]; // works in D
> }
>
> It even simulated PHP's session_start() thing, though bugs in
> std.variant kept it from being particularly useful at the time.
> While std.variant is now fixed, I haven't had a need for sessions
> like that, so never updated that to the new module.
>

I don't know how yours works, but PHP's session system has a number a pains. 
The whole way it handles session timeouts is just bizarre, and the fact that 
it's even possible for the sysadmin to enable session.auto_start has caused 
me big headaches.

Actually, that get's into one of the big things I hate about PHP: there's 
far too much it allows sysadmins to fuck with. And it's not always possible 
for the programmer to override dumb php.ini settings. As a result, even a 
single specific point release of PHP is essentially 5 million different 
languages, depending what server you're on and your sysadmin's day-to-day 
whims. And a lot of the settings are just stupid features that never should 
have been put in in the first place (granted, those ones tend to become 
deprocated, but by then the damage is already done).

Which reminds me of the PHP4->PHP5 debacle. I can certainly appreciate the 
occasional need for changes that break backwards-compatibility (especially 
as a D user), so I don't have a problem per se with the fact that PHP5 broke 
backwards compatibility (although it's not like compatibility in PHP has 
ever been anything but a joke). But there are so many ways it would have 
been so trivial to avoid the problems it caused. Probably the simplest and 
most obvious would be a decree "Scripts targeting PHP5 and up must end with 
the extension .php5, otherwise it will either refuse to run or get sent to a 
PHP4 installation if available." Or instead of the extension, require the 
first line to be "<?php PHP5...", etc. So many easy ways to avoid the 
problems they had. And that's all just off the top of my head. But PHP's 
primary design principle seems to be "Be sloppy whenever possible."

Of course, D2 broke backards compatibility with D1 and doesn't have anything 
like what I suggested above for PHP5. But it works for D because the 
language exists completely on the development side, not on the server side 
like PHP.

>
> For some reason, I actually liked it at the time. But, it broke
> down when I decided to write my own little http server to avoid
> Apache bloat for an app.

Cool :)

It's amazing how simple a basic http server is. Yea, there's some details 
and gotchas to be careful of if you're really trying to follow the HTTP1.1 
spec properly (which is probably a good idea anyway). But even still, 
someone who's never written a server would probably think it would need to 
be some major Apache-level undertaking. That's what I originally thought. 
But unless you're really going for 
super-flexibility/configurability/bells-and-whistles, etc., you really don't 
need 99% of that, and it actually ends up being pretty simple.

...Unless you want to run it on a shared web host. Then you're just plain 
shit-out-of-luck ;)

> A shared, mutable global is obviously
> nasty there.
>
> (I did stick with it for a while, but it got so complicated I
> ditched the whole stupid thing and started over, writing the
> new class based cgi.d. If you look at my code though, you'll see
> a couple things that are very bizarre according to the CGI standard:
> these are the things that let it work with the embedded httpd too.
> It reads all headers itself and writes the raw protocol to sockets
> instead of stdout when constructed that way. Thus, aside from the
> constructor arguments, the rest of the client code looks the same,
> so I can switch from embedded to apache/iis and back easily enough.

That's pretty cool.

> The functions being mixin GenericMain!() instead of main() is also
> due to this, though the try/catch it provides is nice too.)
>
>
> Anywho.
>
> Another bad experience with PHP led me to make the get and post
> vars in cgi.d completely immutable - something that leads to
> some pain, since phobos and druntime don't care much for
> immutable(char[])'s (instead opting to work with
> immutable(char)[]'s. This has gotten worse in the new beta with
> even the replace() function no longer working on the former! Ugh!)
>
> But, some minor hacks here and there make it work, so yay.
>
> And, unlike PHP, if some asshole decides to write $_POST["evil"] =
> $whatever; in his vile function, I won't have to deal with it later!
> Whoo hoo!

Yea, D kicks the snot out of PHP in so many ways. It's so unfortunate though 
that shared web hosts have SOOO much better support for PHP than 
native-compiled CGI. I suppose one could argue that's for security and 
reliability reasons, but PHP's known for being terrible in those areas, too. 
*shrug* Just a popularity thing I guess...It annoys me to no end that the 
computer world has become every bit as trend-driven as the high-fasion 
industry...I guess that's what happens when you let middle managers in on 
things.




More information about the Digitalmars-d-learn mailing list