On Tue, Jun 19, 2001 at 02:31:31PM +0100, Steve Purkis wrote:
> Unfortunately, Perl's flexibility also makes it hard to develop
> procedures for ;-)
C shops manage to do it, and C is just as flexible in terms of what you
can do.
I was thinking more about having good rigourous code review, and a clueful
development team leader who the team will respect when he suggests breaking
some lump of code out into a seperate module.
> In general, I think tools like TT are going down the right path.
> But I think that, ultimately, this problem can be solved by introducing
> a simple java/ECMA-script like language into the ``html'' layer purely
> for presentation logic and access to application data.
Server-side Javascript is actually rather nice as a language, but it's a
swine of an environment. And, of course, it gets used for a lot more
than just presentation layer stuff.
> The quick alternative to this is to build javascript data structures
> with your application & use JS in combination with DHTML to generate the
> pages clientside. (disclaimer: i may have been on crack when i wrote
> this ;-)
Yes, you were tripping :-) For that to work, you'd need:
secure Javascript (yeah right)
including security against resource starvation, like:
for(;;) { }
standard Javascript (yeah right - Netscape can't even standardise the
language they created, let alone the Netscape vs MS (vs other MS,
vs MS on Macs) issues)
standard DHTML (yeah right)
and it would need to degrade gracefully so that (for instance) search
engines and PDAs could make sense of your page.
> Anyway, if you combine the scripting idea with something that's been
> kicking around in my head for the past year - namely that Perl needs a
> good `Application Server' ...
Yes, a proper application server would be a good thing. This has been
discussed here before, particularly in relation to Zope.
--
David Cantrell | [EMAIL PROTECTED] | http://www.cantrell.org.uk/david/
Good advice is always certain to be ignored,
but that's no reason not to give it -- Agatha Christie
