MVC - the 'meme drift' was Re: return(bless $rant, $class) || Fwd: PHP vs Perl
On Wednesday, Jul 30, 2003, at 06:28 US/Pacific, Ovid wrote:
[..]
hi ovid, et al,
let me first start with a bit of Dan Akroyd of SNL fame,
"Ovid, you spawn of a hairless ape"
The good news seems to be that we DO agree that a root
cause analysis of the 'MVC as meme' can be laid four
square upon the 'Gang of Four' - as you call them,
and were I not lazy I would actually haul down their
tome and cite the ISBN
[..]
if people are learning about MVC from the discussion on this list,
it is probably a good thing that they know a bit of the history of
said pattern rather than assume that it was coughed up from the void
fully formed in the way that it's being discussed on this list.
But I am s not sure that the history will help the discussion,
in part, since the 'meme' has drifted and gained a sense of
orthodoxy all out of proportion to the underlying argument
as you note with:
I am not saying that the GoF presented the only correct view of
how MVC should work (in fact, I object to a common interpretation
that DP can only be used for OO languages). However, the original
point of Design Patterns (the architectural ones preceeding the
programmatic ones) was to give people a common vocabulary so they
can discuss a situation and know what each other is talking about.
A part of that problem is the presumption that 'OO' provides some
mystico-religious solution that is inherent in the 'language'
rather than that the ideas have been implemented 'better' or 'worser'
in this or that 'programming language'...
Which of course is the Really Comical tid-bit in the midst of a
kvetching
about PHP v. Perl
Unfortunately, at this point in history, I fear you are being
a bit optomistic that "Design Patterns" were intent upon
providing a common 'vocabulary' - as much as to generate
buzz, and from that buzz to 'sell product' that 'implemented'
a given variation of the meme in drift...
While I may be merely being pessimistic in my interpretation.
We do at least agree that the myth of legend is that the intention
was to produce UML - the Universal Modelling Language - and that
it would provide the one true, formal, and applicable language in
which the TrueBelievers were going to build the great Tower of Babel
based upon the correct implementation of the MVC Design Pattern...
{ this might not be the polite point in the chat to note that
'design pattern' is a buzzPhrase ripped off from other fields
of human endeavor outside of the 'computing world'... and that
the hope underneath the UML/MVC, Design Pattern, et al, was that
we would successfully replicate the 19th Century Notion of the
Factory System in the information age... but that way may be
a bit more unpleasantly complex in its relationships than we
would prefer to cover here... }
[..]
If the people on this list are handed a version of MVC for the
Web and have no idea of the history and origins of said pattern,
then someone who only knows it from the GoF description is going
to have a very confused conversation with someone who doesn't
know the GoF description.
Which of course is the Ultimate Irony of the whole FREAKING Problem.
If a 'design pattern' were suppose to be the portable intellectual
abstraction of a given 'class of problem' - independent of the
actual underlying implementation specific details - then the fact
that we have two groups who come to the same 'design pattern' and
lose the ability to talk about what is merely an abstraction because
of the differences in the underlying implementation specific details
leads me to wonder if the vary concept of a 'design pattern' was,
well, 'weak' and/or 'lame' to begin with Hence my concern that
it was merely 'marketting speak' to bring in new converts to the
cooler cult... rather than finding "God's True Divine Will"
No either description is necessarily good or bad, but they have
significantly different implementations and that's an important
difference.
[..]
The question then becomes can 'abstract ideas' be ported
around from system to system? Anyone who has dealt with
say Java's
try{}throw{}catch{}
structure of course has the giggle moment in the discussions
about the differences between ErrorClasses and ExceptionClasses,
since, well, it's not too clear how to manage the
ErrorClassForCoreDump
Yet, we have seen things like FatalToBrowsers provide a way to
'catch' the 'die' that was 'thrown'{ or should we have said
that 'the die is cast' }
So either we can decide that a 'meme' in it's original intention,
such as the MVC Design Pattern, is worth at least knowing about
and working out how best to use the 'best practices' that it
attempts to establish - or we should follow the 'meme drift'
and decide that Perl Is Dead, because
NewCoolerCodingFooIsTheWave
So I will fully support you in the war against 'meme drift'
since good ideas remain good ideas, even if they are not as
easy to implement in any given coding language...
and of course, as we all know from the hot buzz 'meme drift du
Re: MVC - the 'meme drift'
--- drieux <[EMAIL PROTECTED]> wrote: > But I am s not sure that the history will help the discussion, > in part, since the 'meme' has drifted and gained a sense of > orthodoxy all out of proportion to the underlying argument > as you note with: drieux, "Design Patterns" were originally a tool to provide a common language. If the current discussion of MVC differs significantly from the original (historical) implementation of MVC as described by the Gang of Four, then we're going to have a problem if programmers do not understand this distinction because a "common vocabulary" no longer exists. In other words, we can't use common terms if we don't realize that our definitions differ. For example, arguing over whether or not "change" is important is pretty silly if I don't realize that I am talking about a verb and the other person is talking about a noun :) Which brings me to my next point: > Unfortunately, at this point in history, I fear you are being > a bit optomistic that "Design Patterns" were intent upon > providing a common 'vocabulary' (Disclaimer: like so many others who cite the Alexander book, I've not actually read it. I'm referring to the description by M. J. Dominus. I trust that he knows what he's talking about.) Design Patterns first appeared in a book by Christopher Alexander (though I don't believe he used the phrase "Design Patterns"). This book was named "Pattern Languages" and it was about providing a common language for basic architectural designs (http://perl.plover.com/yak/design/samples/slide011.html). Did the Gang of Four intend to borrow the concept of naming, or did they decide that Design Patterns were these concrete things to be handed down and slavishly worshipped? Here's part of how *they* describe Design Patterns: "A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object- oriented systems." In short: GoF patterns provide a common vocabulary, just as the original Alexander book intended. Mind you, some think that the intention of the GoF was simply to hand out code samples and say "you must do it this way". If you read DP, the authors make it clear that there are good and bad points to every pattern. The point of the book was to give some good strategies for problems and give names to those strategies. Today, I can quite comfortably suggest to a programmer "use a factory pattern" and they'll slap their forehead when they realize how it solves their problem. I do not have to hand them code and say "do this". Naturally, this presupposes that the programmer knows what a factory is. But what happens when I say "use an MVC pattern"? The programmer might say "but I'm writing a CGI script and I don't have multiple Views and Controllers that need to by synchronized and updated." If I didn't know the problem space that MVC was applied to in the book I might be scratching my head over that one. For some interesting thoughts, go read Dominus' presentation on the topic (http://perl.plover.com/yak/design/). I, however, am pretty much done here. I have work to do :) Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Flock Test...
What could be the simplest test to check 'flock' working on your server or not? except for writing to support team of host ::)) Thanks for any input. Sara.
Script for random images -- problem
Hello,
I am getting the following error -->
Software error:
Couldn't chdir to pictures directory: Not a directory at
/home/sites/site175/web/cgi-bin/rand_img.cgi line 11.
Is there setting on Apache that I need to enable so this script will work?
Thanks,
Dave Gilden
#!/usr/bin/perl
# http://www.musiciansdfw.org/cgi-bin/rand_img.cgi/path to images/
# script: random_pict2.pl Thank you Lincoln Stein!
use CGI qw/:standard/;
use CGI::Carp qw(fatalsToBrowser);
$PICTURE_PATH = path_translated();
$PICTURE_URL = path_info();
chdir $PICTURE_PATH
or die "Couldn't chdir to pictures directory: $!";
@pictures = <*.{jpg,gif}>;
$lucky_one = $pictures[rand(@pictures)];
die "Failed to pick a picture" unless $lucky_one;
print redirect("$PICTURE_URL/$lucky_one");
__END__
==
Cora Connection: Your West African Music Source
Resources, Recordings, Instruments & More!
Help Re-writing my if statement
Gidday All,
I would like to write this if statement better by combining the two
elsif conditions.
if( !&check_url ){
print 'The Referrer
'.$ENV{'HTTP_REFERER'}.' is not allowed to access this
cgi-script!';
}
elsif( !&check_email( $data{'toAddress'} ) ){
print 'An email cannot be sent ' .
$data{'toAddress'} .' is not a valid email address.';
}
elsif( !&check_emailDomain( $data{'toAddress'} ) ){
print 'An email cannot be sent ' .
$data{'toAddress'} .' is not a valid email address.';
}
else{
}
I tried this with no success
if( !&check_url ){
print 'The Referrer
'.$ENV{'HTTP_REFERER'}.' is not allowed to access this
cgi-script!';
}
elsif( !&check_email( $data{'toAddress'} ) && !&check_emailDomain(
$data{'toAddress'} ) ){
print 'An email cannot be sent ' .
$data{'toAddress'} .' is not a valid email address.';
}
else{
}
Thanking you in anticipation
Colin Johnstone
**
This message is intended for the addressee named and may contain
privileged information or confidential information or both. If you
are not the intended recipient please delete it and notify the sender.
**
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Script for random images -- problem
On Thu, 31 Jul 2003 17:58:43 -0500, David Gilden wrote: > $PICTURE_PATH = path_translated(); > $PICTURE_URL = path_info(); > chdir $PICTURE_PATH > or die "Couldn't chdir to pictures directory: $!"; Hello David, 'perldoc CGI', '/path_translated' did return the following information: path_translated() As per path_info() but returns the additional path information translated into a physical path, e.g. "/usr/local/etc/httpd/htdocs/additional/stuff". The Microsoft IIS is broken with respect to the trans- lated path as well. This means that everything will be returned INCLUDING the filename of your script To solve this problem you just might want to delete everything after the last slash as in so: substr $picture_path, rindex $picture_path, '/'; More information about the function used can be found by using perldoc -f rindex perldoc -f substr in the terminal/shell. BTW. It's also okay to print your variables to the screen or a log file, so that you can see what value is actually reached into chdir. thanks /oliver/ -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
