Simon Wistow <[EMAIL PROTECTED]> writes:

> I've recently been rolling yet another home brew CMS and I remembered
> how much I hate doing CGI stuff even with all the advances since I last
> did it - there are application frameworks and templating systems and ...
> and ... it still sucks. As a way of doing applications http and CGI suck
> ass. As well they should, they were never designed to do such a thing.
> And as a GUI html sucks as well. Same reason. 

CGI was fun in 1996 but six years on there has to be a better way of
doing this and programming using a better API or higher level
abstraction since modern programming is less about actually writing
new code and more about how you build on the frameworks supplied to
you by other programmers.  This means you have to do more reading of
code before trying to write it but this is a Good Thing.

One bad thing about HTTP/CGI is basically the lack of state and a
session layer and the solution is too abstract it away!  Yet the cogs
hidden below the shiny objects are the same old cookies and URI state
we hate.  And you will still need to know how cookies work to debug
and test problems.

With Perl you have numerous choices (as ever both a strength and
weakness) of 3rd party CPAN CGI abstractions. I liked CGI::Application
and wonder what other modules do people base their CGIs on?  Or is
your structure a 'if elsif else' using param('command')?

One problem is HTML and CGI integration and how you tie these two very
different things together (created by two very different people -- a
programmer and designer) to overcome the obvious impedance mismatch.

The most popular solution seems to be to mix code and presentation in
flat text files.  Some people even use the code of another language to
confuse things further.

Using something like a MVC model seems a better solution where the
HTML is just a view which could be WML or XHTML or whatever.

> That way applications will automatically work on either on the desktop
> or as a 'web' based app through a browser. Or something. Either that or
> someone will invent a language that will do everything transparently and
> automagically but still through http and html.

This sounds very much like the old Netscape dream of 1996 of the
browser as the desktop with Sun's Java stuff embedded in it.

Java basically failed client-side because the typical desktop machines
around at the time weren't up to the job of actually running the
applets other than displaying a grey square and thrashing the disk.

By the time it worked (only a year or so ago) Microsoft pulled Java
from their browser.  There has been no "killer app" applets and the
role that Java should have had was taken by Flash.

I think this was a pity and the idea of a well designed OO-based
language (with platform independence and security as key goals)
running on everyone's desktop was a good one and maybe one that will
return.

-- 
Steve Mynott <[EMAIL PROTECTED]>





Reply via email to