|
7.4 Avoiding Errors And Inconsistencies FunnelWeb provides the opportunity to eliminate all kinds of errors and inconsistencies by replacing text names with FunnelWeb macro names that cannot be misspelt without being detected by FunnelWeb. This page provides some examples of this.
Have you ever done this:
This is <B Very Important</B>! These kinds of errors can be eliminated by replacing HTML constructs, even simple ones, by FunnelWeb macros:
@$@<B@>@(@1@)@M@{<B>@1</B>@} ... This is @<B@>@(Very Important@)! While this is a bit messier, it eliminates the chance of an error because if you get the syntax wrong, FunnelWeb will generate an error at "compile time", which is a lot better than receiving email from some random web visitor. It's true that the same level of checking can be obtained by running an HTML syntax checker over your web. However, if you're using FunnelWeb for all its other benefits, you might as well use this aspect too.
Another source of error in webs is bad internal links. This can occur when you rename a file and forget to "fix up" all the links to it, and when you make a typing error when typing in a filename in a hyperlink. You can use FunnelWeb to eliminate both of these kinds of error, by defining a macro for each output file. This is easier to do than explain:
@!************************************************ @$@<Begin page@>@(@1@)@M@{ <HTML> <HEAD> <TITLE>@1</TITLE> </HEAD> <BODY BGCOLOR=#FFFFFF TEXT=#000033> @} @$@<End page@>@M@{ </BODY> </HTML> @} @!************************************************ @O@<index.html@>@{ @<Begin page@>@(Dave's Home Page@) <P>Welcome to my home page. Check out my <A HREF="@<Links FILE@>">links page</A> and my <A HREF="@<Hobbies FILE@>">hobbies page</A>. @<End page@> @} @!************************************************ @$@<Links FILE@>@M@{links.html@} @O@<links.html@>@{ @<Begin page@>@(Dave's Links@) <P>Here are my links: <P> <A HREF="http://www.yahoo.com/">Yahoo</A><BR> <A HREF="http://www.dilbert.com/">Dilbert</A><BR> @<End page@> @} @!************************************************ @$@<Hobbies FILE@>@M@{hobbies.html@} @O@<hobbies.html@>@{ @<Begin page@>@(Dave's Hobbies@) <P>This page is under construction! @<End page@> @} @!************************************************ Again, this technique introduces a little messiness, but the benefits it brings are significant. Once you have deployed this technique throughout your web source file, you will then be free to change the names of any of your files without ever having to worry about fixing up any links - they will all be fixed automatically! Furthermore, if you delete an output file from your FunnelWeb source file, FunnelWeb will alert you to any "dangling links" because the references to the deleted page take the form of calls to a macro that is no longer defined! Of course, this only works if you don't mark your filename macros with @Z. The only thing you have to get right is to ensure that the filename of the output macro is the same as the value of the corresponding naming macro. This isn't too hard to do because they are always on adjacent lines. The benefit of eliminating all bad links from one's web is a benefit that can be obtained by running an external web analysis tool over your web. However, by using FunnelWeb file naming macros, you can be SURE that the web can never be generated with a bad link, whereas the web analysis tool only works if you remember to run it!
Sometimes you might have to create a web that contains lots of long names that are hard to remember or spell. FunnelWeb can help here by eliminating the chance of error. Just define each name as macro and always call the macro when using the name. The benefit of doing this is that FunnelWeb will always detect a spelling error because if you make a spelling error in the macro name, FunnelWeb will generate a "macro not defined" error.
@$@<Marvin Hylrzbvwryvitz@>@M@{Marvin Hylrzbvwryvitz@} If you want to, you could used a shortened form. For example:
@$@<Marvin@>@M@{Marvin Hylrzbvwryvitz@}
One of the organizational challenges of implementing CGI form processing is getting all the field names right. Because (normally) the form is in one file, and the CGI script that processes it is in another file, it's very easy to accidentally use different names for the same field. For example, you might use email_adr in one and email-adr in the other. FunnelWeb can be used to completely eliminate this problem as follows:
Here's an example:
@!************************************************ @$@<Email FIELD@>@M@{email_adr@} @!************************************************ @O@<order.html@>@{ @<Begin page@>@(Order Form@) <P> <FORM ...> <INPUT TYPE="text" NAME="@<Email FIELD@>"> ... </FORM> @<End page@> @} @!************************************************ @O@<order.cgi@>@{@- @<Begin CGI page@> ... $v = $form{'@<Email FIELD@>'}; @<End CGI page@> @} @!************************************************ This technique more or less completely eliminates mismatch errors in form field names, for if any such error is made, FunnelWeb will generate a "macro not defined" error. All you have to do to benefit from this technique is get into the habit of using it.
Many people who write HTML directly use nerve wracking multi-file global replaces to perform the kind of web parameterization that FunnelWeb makes so easy. Unfortunately, these global replacements can go badly wrong because the target text may be used in many different contexts. In some cases, this approach fails completely. For example, suppose that you have to create a hundred page web that has to be laced with two email addresses: a "business" email address and a "personal" email address. No problem so far. However, suppose that you haven't yet chosen a business domain name and, as a result, at the current time, the two email addresses are the same! If this were the case, you would have to put your address throughout all the pages and would LOSE the information of which were supposed to be business addresses and which were supposed to be personal ones. FunnelWeb solves this problem (and others like it) completely by allowing you to define two macros one for each context. For example:
@$@<Business EMAIL@>@M@{dave@@someisp.com.au@} @$@<Personal EMAIL@>@M@{dave@@someisp.com.au@} These macros can then be used as appropriate. Later, when the domain name comes through and the business address changes, all that needs to be changed is a single definition:
@$@<Business EMAIL@>@M@{dave@@megacorp.com.au@} @$@<Personal EMAIL@>@M@{dave@@someisp.com.au@} There is no need to perform a multi-file global replace and evaluate the context of the use of each email address, as the information was not lost when the web was originally created, because of the two macros. This example is just one of many similar situations that arise. By locating all the pages of your web in a single file and allowing you to define macros for different purposes, you can eliminate much of the time and danger of global replacements.
Webmaster Copyright © Ross N. Williams 1992,1999. All rights reserved. |