|
in reply to Re: Ignorant Article
in thread Ignorant Article
This node falls below the community's threshold of quality. You may see it by logging in. |
Re: Re: Re: Ignorant Article
by steves (Curate) on Feb 18, 2003 at 16:51 UTC
|
So where are these other pages of the article? The one I read has a title at the top, footnotes at the bottom, and no paging buttons or links.
I am not a JavaScript advocate. I was merely trying to find out what these other presentation technolgies are that the article alludes to. The bulk of the article laments the fact that CGI's are tied to HTTP and HTML. So is the rest of the web, so what's the point?
CGI is not Perl. CGI is a way of providing dynamic content. The fact that there are other wrappers around that doesn't change the fact that under it all the same limitations and issues exist, regardless of technology used or language. So in that sense, much of the web (other than static content) is basically a CGI model, usually with some sort of wrapper around it.
We (or I) obviously hit a nerve based on the tone of your response. I was merely trying to take the points I saw as inaccurate and point out what I see to be the truth. Why does that bother you so much?
I have, by the way, written dynamic web back-ends in C, C++, Java, and even with shell scripts so don't assume I live and die by Perl. I use the best tool for the job at hand. I can't help it if much of the time that's Perl. 8-)
| [reply] |
|
|
| [reply] |
|
|
| [reply] |
|
|
Steves,
You can get the full tutorial at....
http://www.extropia.com/tutorials.html
| [reply] |
Re: Re: Re: Ignorant Article
by hardburn (Abbot) on Feb 18, 2003 at 16:57 UTC
|
The problem is not (ultimately) CGIs. It's HTTP. Any technology built on HTTP is going to run into the same issues. You're going to have to use some sort of kludge to get any sort of stateful information over HTTP, be it hidden input forms or cookies or whatever else. Asethetically, these are all awful solutions.
Replacing HTTP as an application platform would be wonderful. J2EE doesn't do that, and we shouldn't pretend that the handwaving it does is any less kludgy than solutions CGIs use.
----
Reinvent a rounder wheel.
Note: All code is untested, unless otherwise stated
| [reply] |
|
|
Your point is quite right I think. There are certain weaknesses built into HTTP that makes session management more difficult, though I don't know if I would consider all solutions kludges.
From an enterprise developers point of view, so long as you wrap a kludge in a strong enough component with a cler enough public API, then that is fine.
CGI.pm does a wonderful job at this and I am proud to say that Lincoln took comments from Gunther and me, while we were at the NIH Genome Project, when designing it.
That said, I equally enjoy working with Servlet Containers.
In the end, once objectified, so long as the kludge works, provided it is a black box to me and works, as a developer, then I am more or less satisfied.
I don't know if I would geive up HTTP though. I may just be old fashioned, but I rather like it as a standard.
- Selena Sol
| [reply] |
Re^3: Ignorant Article
by Coruscate (Sexton) on Feb 19, 2003 at 00:22 UTC
|
Eric, I don't know you from a hole in the ground, so I don't have anything personal against you. However, it doesn't mean I don't have my opinions. :)
I could have been a great ally to Perl CGI
Wow, that's news to me. There's a way to ban people from writing and executing Perl scripts? I can be quite sure there is no power in existence that told you "you cannot join the Perl community".
The fact is that you are reading this article COMPLETELY out of context as you are missing all the pages before and after.
If it is possible to read that article out of context, then I'm guessing that enough thought didn't go into writing it. Just a guess though. BTW, what pages before and after? I see no links to previous or next pages.
Cookies are a different state mechanism covered in a different page of that article. Obviously, you are ignorant, not the article.
Once again, what other pages? The web author that physically posted these different pages of the artcile (whether it was you or somebody else) obviously was ignorant to the fact that web surfers enjoy getting to the next page of an article by clicking a link, not by attempting to find it by starting at the home page.
Cookies are one of the slippery slopes ... I prefer all logic to be in the controller.
By 'controller', do you mean the server? If not, then I am ignorant in this case and you can ignore the following lines. I'm sorry to say that not using cookies is really quite a burden. You can't store session information based on an IP address because of dynamic IPs, and using a hidden field on every single page of a site is just a pain in the ass. I'm all for cookies, as long as they are only used to point to a particular session. I'm _not_ for storing all data on the client side. The actual data corresponding to a session belongs on the server.
That you are so keen to suggest JavaScript shows me that your conception of basic design patters is shoddy
Hey, something we agree on! JavaScript deserves to be shot in the foot and tossed overboard :)
But the weaknesses of HTML and even dHTML are important issues that the community should help to address rather than deny.
I'm interested in hearing more about this one. So HTML is limited. What can we do about that? The last thing I need is for web designers to be given more power than they already have. I don't _want_ to surf the internet with fancy things flying all around. I quite like the fact that sites are restricted as to what they can do. Perhaps we could suggest that all webmasters create downloadable programs for each site they make to provide a fancier, friendlier, more appealing user interface? Oh yes, I'd just _love_ to click a "Click here to download our 100MB software bundle so you can view our site" link every minute or two. Besides, this software would be more buggy and open up hundreds of security holes in itself, much more than a CGI program or script running on the server.
As for flash and VRML: I hate both of them beyond hate :) The only reason people use these is to move beyond the limits of HTML is to create flashy animations and virtual worlds where you get to walk around. As I already mentioned, I don't like flashy things (ie: Flash). I don't like sitting at my computer for 2 minutes while I watch a Flash script roll text around my screen creating a menu: I want the menu instantly. It doesn't help that some idiots won't put in a 'Skip Intro' button. Grr :|
If the above content is missing any vital points or you feel that any of the information is misleading, incorrect or irrelevant, please feel free to downvote the post. At the same time, reply to this node or /msg me to tell me what is wrong with the post, so that I may update the node to the best of my ability. If you do not inform me as to why the post deserved a downvote, your vote does not have any significance and will be disregarded.
| [reply] |
|
|
I did not mean to suggest that anyone told me to get out of the perl community. I meant to say that....
I was with the Perl community since CGI was born and I have been through many things with many Perl sub-communities.
Now this is no fault of you or PerlMonks, but "in general", I feel that the Perl community fell into a place that I no longer wanted to be a part of right around the time Java, PHP, and ASP really started getting strong.
It also corresponds to when Tom C wrote 'Perl Cookbook' which is technically a fantastic book.
Something happened to the community then.
IMHO, it got really snobby and critial. It forgot all about TMTOWTDI. Suddenly, anyone coding Perl 4 was not only a loser but...dangerous.
People like Monk Dave, called pioneers like Matt Wright and me, "dangerous" and "ignorant", when in fact we were brave enough to stick our necks out and not only build functional tools at the dawn of the revolution when we had NO refernece models, but document them well enough that many people could use them. We inspired a generation of programmers,some of whom like Stas Bekman of the mod_perlcommunity, became the gurus of today.
In both cases, we did this for years without being paid - out of our love for the community.
Granted, Matt did not keep up with security issues as fast as we might have hoped, but he had a life to lead too...you know....he had to pay rent.
If only the nms site, which is a fantastic idea, had happened without name calling. If only people had used our open CVS tree which was on sourceforge for many moons.
But that did not happen. Instead....smear campaign.
For my case, our tools were updated as quickly as possible. We did have security holes, but so does everyone. We did have bugs in our code...but so does everyone. What matters is that we responded quickly when issues were presented. We were one of the first sites to move to taintmode, for example. We fixed the cross site scripting hole 10 hours after it was announced.
....
I think that maybe this culture change was a defensive reaction to competition and possibly it was a reflection of a new breed of gurus (who cared more about technology) taking over from the first generation (who cared more about people).
Whatever the case, for me, Perl became a much unfriendlier and less tolerant place to be, and it eventually "pushed me out".
I don't want you to feel that I have anything against Perl Monks or you. Actually, you guys stopped "me" from flaming which is something I rarely do, cause if you got to know me you would see that I almost never participate in a
flame war.
It is just that I am really burned on the Perl community at large and at the moment, I don't want to risk investing my energies again into something that I have lost faith and trust in.
| [reply] |
|
|
When I refer to "controller", what I am talking about is the "C" in the MVC (Model-View-Controller) design pattern.
Simplistically, this design pattern suggests that an application should be divided into three isolatable parts...
- The presentation layer (View),
- The data (Model) and,
- The Controller (the business rules that take data from the presentation layer and manipulate it into the model).
This design pattern is especially effective in web applicaiton development.
| [reply] |
|
|
In terms of what you can do to reduce the weaknesses of HTML I would say the number one thing is to use Template::Toolkit or another good templating module set in whatever language you are using.
Beyond that, you can get more involved with design as a programmer and you can help designers get more involved with code (THat is where TT can help alot).
IMHO, the goal of most software design is to solve a human problem....to make people more efficient....not to write the most efficient algoithm or to use ADSL bandwidth like it was a 9600 modem.
People are strange.
They like nice design. In fact, they like nice design so much that they will choose design over functionality in many cases.
Is that lame? Maybe. But it is the way people are wired and there is no use fighting it.
Now I am not a big fan of the BLINK tag, but I also want my software to be used heavily and to solve problems. If that means making my design nice, then I am happy to spend just as much time on design as algorithms.
At the same time, sites and applicaitons should also cater towards people who like 'just the facts'....people like you....or...perhaps more impotrtantly, people who are blind.
So design should not surpass the fact that the goal is to solve a human problem, just like coding should not.
| [reply] |
|
|
As for why you cannot get to the next page from the WDVL site...I have no idea. I have nothing to do with that website. It is one of many that mirrors my tutorials and I have no control over how they do it. When you read the original site you will see that I provided previous and next links as standard.
| [reply] |
|
|
As for reading the tuorials, I appologize for the amount of time it is taking to get the eXtropia website back up. My sys team in Singapore is working on an urgent project and they decided to finish it upbefore they attend to the web server. I expect it will be upsoon and I will let you all know when it does and where the tutorials are.
| [reply] |
|
|
