On Tuesday, Jul 22, 2003, at 20:10 US/Pacific, Wiggins d'Anconia wrote:
Octavian Rasnita wrote:[..]
Of course, he was talking about CGI programming, because I know that Perl
can do much more than CGI programming like PHP.
As much as we jest at your expense I suppose a "real" answer should be given, well other than drieux's long rant about MVC and layers ;-).
first off, I actually wish that the process of WOOFing up 'browser neutral' 'html like stuff' WERE simpler, { and that there was BUT one DOM, vice 3++ } and as such, there are things in PHP that 'simplify' some of that - just as
use CGI;
helps in some cases.... so it really is not a matter of jesting at Octavian, as much as it is the HORROR that HTTP/HTML/XHMTL/XML/XPATH/XSLT/OtherWordsWithX_inThem were not so much 'released' as LEAKED OUT like toxic waste.
As such we have all been improvising ways to 'woof Up Html Stuff',
whether in PHP or Perl... All too often, because someone saw
a web-page somewhere, and it did something like this doodle
on a cocktail napkin.... { make sure that you talk with the
graphically enabled person when getting 'what the customer
really wants' - ESPECIALLY if the customer is both colour
blind, has no sense of spacial orientation, and generally
is not into 'graphics'. Ok, you should also make sure that
they have been on Planet Earth LongTime, and didn't just
fall off the MotherShip, YOU try to get a collection agency
going after a Klingon who loves opera, but can not sing well... }Then there is the problem that anyone with a decent "Graphics Package" can whip up gifs for buttons, and make really cool things that will work as a 'mock up' of what the Human Interface 'should look like' - but this only gets you to the 'mock up' - and while that helps at the level of having the Customer go 'ook-ook, look pretty' this is where the 'cgi stuff' gets 'ugly' - since if it really is a 'middleware' solution - that is bridging between the 'cool graphics' at the browser side, and any level of technical complications back at the server side - then you have to start making decisions about whether or not you want to cache information in cookies, or do you use hidden values, or what to pass information around - On Top of the basic 'select from menu' and 'click check boxes' and 'fill in the form' processing.
In short 'how dynamic' is the 'dynamic webpage' that you are creating - and what is the 'underlying stuff' that one is grongelating through, or trying to do.
Those Mock Ups will help solve at least the 'presentation' portion of the problem - both in terms of how to get the person poking the page to poke the right things, as well as how you return the 'response' to their poking and proding.
[..]
[..]The closest answer is "whatever works best in your situation". The problem with this answer is there are at least a hundred different factors in determining what your situation is, and even if you could define it that explicitly there would still be overlap of features, etc.
Where this somewhat fails is that I might have argued not that long ago that one would be better positioned were one to construct the 'perl code' - in modules - as I do, and test that the underlying 'controller code' can work as a stand-alone
dumb.plx
that I can run at the command line - and then knowing that I can get all of the right information back as an '@menu_list' that I could then unwrap into html to show up as
<select name="q_host" size="1">
<option value="4.01">4.01</option>
<option value="8049">8049</option>
<option value="1">1</option>
<option value="8347">8347</option>
<option value="2333">2333</option>
</select>which I so love - because this is actually an instance of "OOOPSIE" - since the same "Named" piece of "foo.cgi" exists on the 'remote web-server' - it is just a rev back, running an out of date version of the underlying Perl Module, and the 'correct' new style one would have done say:
<select name="q_host" size="1">
<option value="xanana">xanana</option>
<option value="libex">libex</option>
<option value="jeeves">jeeves</option>
</select>So having a Perl Module didn't save me, and using HTTP as the session layer to 'query back to the config host' didn't save me from a 'version skew problem'.
I'm not convinced by my own demonstration here, that clearly PHP must be better....
I think a part of why the PHP v. Perl 'flame wars' gets going is that at times folks change 'cults' for the wrong reason. They ran into a problem that was less easy to 'code up' in Perl - and because they could use 'fewer lines of text' in PHP - that this must mean that PHP is better at 'generating' 'web-pages' - hence must be better at being the CGI friend...
One of the coolest answers is at:
http://us2.php.net/manual/en/faq.languages.php#faq.languages.perl
where it notes that Perl is a complicated language that comes from a time before the web.... whereas PHP was built specifically for the web side of the game... Great!
I think that a lot of folks can tell a PHP driven 'web site' - just as more and more are able to ID wiki sites - from a full tilt tomcat java server site from an Adobe GoLive site...
And for those who happen to connect to
http://localhost:631/
to connect to their CUPSd.... they should crawl into the source code for that, and have a 'life moment'....
So there are still at least 96 other factors that will go into the process of picking out which is a person's preferred 'html like stuff woofer' system - I think it helps to look at the various ways that 'CGI' gets implemented - and figure out whether one can 'implement, update, maintain, refactor, re-implement and reuse' stuff if one started in code language foo or bar....
I like perl precisely because it is a glue language, and has the full range of sheer silly options, that allows me to write 'cgi code' that can itself turn around and query one or more other servers, using HTTP and other Protocoals, for more dope, that can get wrapped in some 'html like stuff' and woofed out the door to a browser....
Since PHP allows me to invoke 'external commands' - then all I have to do is resolve if that is a faster,cheaper, better way of getting that dope than 'open the socket, push, pull, parse, puke'.
ciao drieux
---
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
