991104.html

((((((((((((((((( WEBREFERENCE UPDATE NEWSLETTER ))))))))))))))))) November 4, 1999

_____________________________SPONSORS_____________________________

This newsletter sponsored by: WRQ, VeriSign, and Fawcette Technical Publications.

__________________________________________________________________

******************************************************************

Free trial available now for SiteScope(tm) & SiteSeer.

Monitor e-commerce system performance, service, & site availability. Find out first via page or email if problems occur. SiteScope software operates from within your firewall. SiteSeer, a 24/7 remote Web service, monitors from outside your firewall. Use both for a complete view of your web site's performance.

https://www.wrqwam.com/intro/web-performance18.html

******************************************************************

Now with over 83900 subscribers!

https://www.webreference.com https://www.webreference.com/new/ https://www.webreference.com/new/submit.html New this week on WebReference.com and the Web:

1. FEATURED ARTICLE: Practicing Safe Code 2. READERS RESPOND: Your feedback to last Thursday's feature 3. SITE NEWS: JavaScript.com launches, wins Netscape "Rage of the Day"

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Every Thursday the Update features a new article contributed by our readers through our Open Publishing Initiative. We encourage you to submit your own article ideas. Those that make the cut receive a free copy of HoTMetaL Pro 6 and a cool internet.com T-shirt!

https://www.webreference.com/new/submit.html

This week, writer Kenneth Tibbetts helps everyone keep their pages clean and their users happy, with his article "Practicing Safe Code."

Spread the word! Feel free to send a copy of this newsletter to your friends and colleagues, and while you're at it, snap a link to WebReference.com. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. FEATURED ARTICLE: Practicing Safe Code

>Forward

One of toughest problems webmasters face is writing code that uses the best features of our visitors' browsers, while not knowing beforehand what software they are running. You can write branching code or redirects, but there are no easy server-side methods to tell if a user has turned off scripting in his 4+ browser. Have you looked at a page that uses positioning with a 3x browser? Not a pretty sight....

From a code writer's point of view, a user getting an error on their page is the worst thing that can happen. Designers feel the same way when their carefully positioned elements are presented to a visitor in source code order, rather than the way they intended. It doesn't really matter if 99% of all users have no problems. That last one percent is what keeps us up at night, wearing the letters off our keyboards.

There are some basics of defensive coding that make some of this a little less work.

>Tip 1: Always Work from the Simple to the Complex

Rather than using a script to try to identify and redirect a visitor who does not have the correct platform or browser to particular pages or scripts, use your script to add more sophisticated features. Imagine the visitor to your page has no script engine at all.

Start with a set of basic pages that can be viewed in the most technically challenged browsers. Your page headers can redirect the advanced browsers after reading the properties of their navigator object. The fancy code can be in pages that can't be clicked to directly, but instead are served up from scripted functions that only send the visitor on if he's got the right stuff.

You can set up some of your links like this:

A browser with no event handling ability will simply link to the URL without even trying the redirect function. A browser a bit more clever will run the function, which can be something like this:

function redirect(){ if(parseInt(navigator.appVersion) The return false allows the default link behavior to return older browsers to the simple link, though if you want, you can have separate pages for any number of versions and browsers.

Just return the new links as true, as this function does for the version 4 and above browsers, to void the link's default behavior.

>Part 2: Use the <NOSCRIPT> Element

Say you have a nicely defined set of pages for scriptless browsers. It's all carefully set up to avoid any links to the killer code you have for advanced visitors. There is still a pitfall that will give you a serious pain before you are through. It's called hypertext.

There is nothing to stop anyone from simply typing an address in their browser and crashing the party you have set up. Or clicking on a link someone e-mailed them, or coming in from a search engine. It's the nature of the Web. Also, a script in the head of every page that tries to weed out the unschooled won't work very well if they aren't running with the same script engine. Most likely they'll see a big mess with your name on it.

It won't do to ignore them - not if you want them to come back when their browsers grow up, or to stay for a while in the shallow end of your pool with the pages that play nicely with everyone.

The <noscript> element works by not being understood. Although it is intended to work in modern browsers by identifying an installed script engine version, the text and html between the opening and closing tags will show up in an older browser. I have a stock <noscript> sequence I put right after the body tag on any page that uses scripting:

A user with no scripting engine, or scripting turned off, will see these links at the top of the page. I put in a 1K pixel tall transparent gif to push the rest of the page's content a thousand pixels down - out of sight for most. Users with scripting enabled will see the page as intended.

Some scripted browsers, like Netscape 2, don't recognize <noscript> and show the content between the tags as if they had no scripting. I just let it go. Navigator 2 is best left to the history of the Internet, and the most basic of pages.

****************************************************************** Expecting a stampede of holiday customers?

Prepare your site with the strongest Web security available. Get our FREE guide "Securing Your Web Site for Business," and learn what you need to know about encrypting Web transactions. Protect your site with 128-bit SSL encryption today and get ready for the stampede!

https://www.verisign.com/cgi-bin/go.cgi?a=n032701950009000

******************************************************************

>Part 3: Code Defensively

Some configurations will be enough on the ball to skip the <noscript> tag but can't render a page that is positioned with styles. To keep these visitors from biting off more than their browsers can chew, I put the same sort of content inside a hidden <div> element that is written to the page immediately below the <body> tag and before the actual content of the page:

<div style="position:absolute;display:none"> <h1>I'm afraid your browser doesn't understand Positioned Styles. </h1> <h2><a href="../shared/helpme.html">Click here for help</a></h2> <h2><a href="..default.htm"> Click here to get out</a></h2> <p><img src="../art/100x1K.gif" width="100" height="1000"> </p> </div>

Again, the user will see the warning and the links only if his browser can not read the style declaration. And at a thousand pixels, that's about all he will see without scrolling down the page. No one else will be aware of it. I would like to say it would do to skip the <noscript> tag and just stick this one in - after all, if they can't read styles they are unlikely to be able to read scripts, right?

But what about someone using a version 4 or better browser who has turned off the script engine? He will render the style correctly, but if you have scripts on the page, he isn't going to get it. And he won't get your message about alternate pages, either. So to be safe, if you are using both positioned elements and scripts, you should put in both warnings. If you aren't using positioned styles, don't put in the second warning.

For someone who is using a browser that is not script enabled and cannot read the page styles, the message will repeat once as he scrolls down the page. Of course, this method doesn't magically make the page work - it just gives the visitor a clue that his browser isn't up to the code, and gently directs him elsewhere.

>Part 4: To Each His Own

The biggest problems you will run into are with users who have some kind of scripting, but not the right kind. Again, the best approach is to go from simple to complex.

Determine what version of the script is the minimum required and put your redirects and warnings in that language. You can't touch Netscape with a function written in VBScript, and if you put your redirect in a 'JavaScript1.2' tag, older versions won't even read it [Editor's note: unless it's a SRC .js file and Netscape 3]. In other words, make the advanced browser walk the walk if they talk the talk, and let the others have the pages they are sitting on.

A good way to check how your pages might be looking to some of your visitors is to put your scripts and stylesheets in external files and comment out their calls in the header:

You will also need to remove any event handlers that call functions from the script:

>body onload="startFunction()"< becomes <body>

This will approximate what the page looks like (and what it does) with no styles or scripting enabled. And, every once in a while, that is the page you should publish. Good coding!

All code examples from this article can be found at: https://www.webreference.com/new/991104_src.html

Author Bio: Kenneth Tibbetts is forty and a bit, married to an artist, and lives in a home they built themselves in central Maine. "I've been writing code since lines really had numbers, but I make my living these days as a woodworker. Care for a nice mahogany notebook computer?" You can contact Kenneth via email at: [email protected], or through his pages at https://www.areoka.com and https://www.yankeeweb.com.

****************************************************************** The Ultimate Web Development Event: CNET Builder.com Live! New Orleans

Get the tools and techniques needed to design better, faster Web sites December 7-11, 1999. Sharpen your Web building skills over 5 days, 50 sessions, and 8 full-day workshops. Evening events in the French Quarter provide unparalleled networking with industry leaders. Register by October 29 and save $200. Mention your registration priority code BEAW for discounts.

Check it out: https://builderlive.devx.com/ltlinktrack.asp?linkid=74

****************************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2. READERS RESPOND: Your feedback to last Thursday's feature

We had a spirited response to last week's article by Stirling Hughes, "Intro to PHP" (you can find the original article at: https://www.webreference.com/news/991028.html#feature). Stirling was kind enough to take the time to reply to some of the questions and issues that you raised. Here are some highlights:

### Subject: PHP vs. CGI

Stirling,

I appreciate the vast selection of Server-side processing options that are available thru web servers these days. Although I don't use PHP, I do follow its progress which is why I read thru your article. As a Perl/CGI developer, I continue to see misinformation being dissiminated by PHP proponents regarding the non-scalability of CGI. Have you never heard of mod_perl or FastCGI? These are scalable solutions for CGI applications just like ASP, PHP, etc. I'd appreciate a better representation of the options when you write future articles.

Regards, William [email protected] www.knowmad.com

###

Dear William, I certainly agree with you, there are many options out there for the Perl/CGI approach, having programmed Perl/CGI for 3 years I have used both mod_perl and FastCGI (mostly mod_perl with some dabbling with FastCGI). There is also ePerl for embedded Perl. They are all very viable options, however, from my experience they are much harder to use and to setup than PHP (in PHP all you need is <? ?>). There is not only that aspect which makes them less desirable, but also the fact that (from my experience) a surprisingly few number of web hosts support them. I definitely agree with you that the same things can be done, however, in my opinion it is much easier in PHP (however I am again a supporter of PHP). Thank you for your time and interest I truly do appreciate all comments.

Best Regards, Stirling Hughes [email protected]

###

Stirling,

Thanks for your well-thought response to my pleas for some fairness about features of PHP vs. Perl/CGI. One thing that I find more difficult to do in embedded scripting languages, such as ASP, PHP or ePerl, is template systems. As a programmer, I work with a team that includes a designer and graphic artist. It is more intuitive to me to split up HTML and scripting pages instead of work on the same document. Does PHP support a templating system so that the GUI and the back-end can be properly separated?

Regards, William [email protected] www.knowmad.com

###

Dear William, There is a lot of support by PHP of what your describing (I believe the technical term is "Modular Programming"). It is done by require and include statements similar to those used with Server Side Include CGI programs. For example, if I wanted to include a standard menu I could do the following.

<? require("menu.inc"); ?> the contents of the webpage

These files that you are including can have PHP code in them which will be executed. On My web site my counter is done with modular programming and classes, the source to the entire website is freely available at https://www.scalarsplit.com. Or the following two site cover modular programming with PHP pretty well:

https://www.hotwired.com/webmonkey/99/25/index2a.html?tw=programming https://www.devshed.com/Server_Side/PHP/Dynamic_Menu/

Yours Sincerely, Stirling Hughes [email protected]

###

Subject: Your PHP article in Webreference...

I have nothing against PHP, but I hardly think that it is fair to compare PHP only to Perl in a CGI context. PerlScript allows the embedding of Perl directly into HTML. It is also free. There are also commercial products that allow Perl to be embedded in that fashion (e.g., Velocigen from Binary Evolution).

I am sure that PHP is a fine language, but I think that you should put all the cards on the table. Otherwise, I enjoyed your article; it was well written and informative.

Cheers-- Al Gaspar [email protected]

###

Subject: RE: Your PHP article in Webreference...

Dear Mr. Gaspar, I certainly do agree with you there are many options with Perl (being a Perl programmer for 3 years I have had experience with mod_perl, FastCGI and ePerl). However as you illustrated there are many, many, many different options for Perl, probably ones that neither of us has even heard of! I agree that perhaps I should have mentioned one or two (such as mod_perl and ePerl since I have experience in them) I left them out because of the length it would take to both explain them and then properly illustrate why I find PHP a better solution. The reason I find PHP a better solution is simply ease of use. For both mod_perl and ePerl (although I have no idea about Perlscript) extensive setup is required for them to be used plus extra code must be written.

However with PHP all that is required is a simple <? ?>. That's it! Not only that but mod_perl, ePerl, FastCGI and Perlscript are not supported by many web hosting providers whereas PHP is. I do agree with you that some attention should have been spent on these other alternatives. I sincerely thank you for your comments.

Best Regards, Stirling Hughes [email protected]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3. SITE NEWS: JavaScript.com launches, wins Netscape "Rage of the Day"

internet.com's newest site, JavaScript.com, launched late last week with a new design and is already receiving kudos: on Wednesday it won Netscape's "Rage of the Day." JavaScript.com is your gateway to all things JavaScript and features JavaScript- related highlights from WebReference, JavaScript Source, internet.com, and features our own Doc JavaScript's Tip of the Day. Congrats to the entire JavaScript.com team!

https://www.javascript.com https://www.netscape.com/netcenter/1999/november/1103_new.html Netscape.com, 991103

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Webref wants you. Yes, you! You too could be in this space, sharing your thoughts with the rest of the WebReference readership. Just submit your article idea at: https://www.webreference.com/new/submit.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ That's it for this week, see you next time.

Andrew King Managing Editor, WebReference.com [email protected]

Eric Cook Assistant Editor, WebReference.com [email protected]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sponsoring the WebReference Update is a cost effective way to reach thousands of qualified buyers. E-mail [email protected] to find out how. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Also on Internet.com .... https://www.Internet.com

Internet News Channel https://www.internet.com/sections/news.html Internet Stocks Channel https://www.internet.com/sections/stocks.html Internet Technology Channel https://www.internet.com/sections/it.html Web Developer Channel https://www.internet.com/sections/webdev.html ISP Resources Channel https://www.internet.com/sections/isp.html Internet Marketing Channel https://www.internet.com/sections/marketing.html Download Channel https://www.internet.com/sections/downloads.html Internet Resources Channel https://www.internet.com/sections/resources.html International Channel https://www.internet.com/sections/international.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To SUBSCRIBE to the WEBREFERENCE-UPDATE: 1. [email protected] or [email protected]

To UN-SUBSCRIBE from WEBREFERENCE-UPDATE do NOT reply to this message, instead: 1. [email protected] or [email protected]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Copyright (c) 1999-2000 Jupitermedia Corp. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WEBREFERENCE-UPDATE is powered by Lyris(R) https://www.lyris.com

991104.html

Find a programming school near you