Re: PHP vs Perl

[drieux]

[..]
Talking about PHP, someone asked me to tell him why is PHP better
and why it is used more than Perl.
[..]

This might be a good time to point people towards the

	MVC - Model, View, Controller

approach for doing software development.
{ just google search on Model, View, Controller for fun }
Web-browsers are a way of presenting a 'view' of
the 'model' - and the web-browser dialogs with
the web-server to 'get stuff done' - this may
mean using the 'common gateway interface' (CGI)
to pass stuff back to a 'controller'....
That controller may be written in perl, it may
actually invoke code that is NOT written in perl.
It might be written in PHP, that understands how
to invoke things written in perl and other languages.
As we have discussed in terms of 'using java scripting'
there is actually a level of 'MVC' that is strictly at
the browser side - and that the server side needs to be
able to deal with the 'failures' that occurred because
the 'java scripting' was ignored, and 'stuff' came
back to the server side - and needs to be managed
by either the CGI code itself - or by the underlying
stuff that it rests upon....
So a part of the problem is

        how tightly wrapped is your 'web-browser side'
        MVC to the 'server-side' MVC(s); and how tightly
        coupled is your 'server-side' MVC's to each other...
At which point we start noticing that there are
'design sillies' in which we forget that the
'server side' is laying on top of other MVC's,
such as database queries, CLI invokations, proxy-ing
through other web-services....
IF one started with a clean, clear and consistent
interface for each MVC on MVC, on MVC, then of
course those will all align correctly and all
will be fine, at least in theory....
Allow me to offer an actual case study. I started with
a general 'abstraction layer' that said
        I need a database thingie, somewhere,
        and I will make my queries to it using a
        CGI based solution.
This way, all of the 'cgi code' that is directly
invoked by the user - calls code that itself will
turn around and query some other web-server as if
we were a 'web-browser' doing a
	GET http://some_db_host:db_port/some/path/db_cgi.cgi?verb=doFoo&val=bob

get the answer back, stuff it into some html
wrappings, and push it out STDOUT to
the user's web-browser.
This allowed me to work out the basics of
what sort of DB I really wanted - so when I
decided what to use at the other end of that query,
I could swap it IN, without changing line one of
the 'cgi code' that the user will invoked.
{ as a general rule, I like to stuff the 'do the work'
side of the problem in a 'perl module' that is external
to the foo.cgi - so that modifications can be done external
to the 'foo.cgi' itself... }
We could of course go the other way with this,
and decide that for 'presentation purposes'
calling a PHP was 'much cooler' - then all I
need to do is teach the PHP to go fetch the
stuff from the DB by using a step in the process
that either knew how to invoke a CGI connection
with another web-server, or invoke some piece
of perl bridge code built with the lwp-useragent,
or roll up something that understood how to open
a socket, woof stuff down it, get a message back,
deconstruct it....
Ok, I must complain here.... there is that other
part of the HORROR STORY - where your beautiful
web application gets 'attacked' because
	"well it's just a 'check box'....."

So now one has to 'just' add

                "<tr><td><p><b>Sysnames (-S):</b></p></td><td>\n" .
                '<input type="text" name="S" value="'.
                '" maxlength="256" onclick="return lineEater()"></td></tr>' . "\n";
to the presentation layer, except of course that also means
updating the java-script to adjust for the shift in fields
of type foo, and then the back side of that cgi code has
to actually pick out the 'S' value, if it exists, then
of course one has to re-write the Freaking Controller,
to figure out how to pass that smack on through to
the CLI interface, so that it will be used, plus the
extension to that Module, to handle all of the new
classes of ERRORS that can occur, because one did
or did not pass that additional set(s) of argument(s),
with or without the newly restructured pre-ceeding Smack,
because the vendor's CLI MVC shifted more than the
	"it is just a "check box" thingie widget..."

Or should I just say, there are other more sinister
plots and conspiracies to really feast upon
than whether you want PHP or Perl to be the
primary source of the 'html like stuff' that
goes back to the user's browser...
ciao
drieux
---

ps: did I mention the part about having to shift
all of the 'online html based documentation' that
goes with the application that will also have to
be clarified where all of the previous illustrations
have been obsoleted by the addition of 'just a checkboxThingie'
not to mention the additional work of providing the primary
documentation about how the user should use it, plus
all of the new error/exceptions that can be thrown,
caught, missed, could barf all the way back to the browser...
pps: is it worthwhile to warn coders to make sure
that their management chain has all human DNA????
Or should they learn the gritty unpleasantries of what happens
when they find that they are working for some Evil Kabal
of BrainWaveSuckingAlienBeastCreaturesFromThePlanetZarkon
on their own ....


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]