By Vince Barnes
Normal provides a WYSIWYG view (What You See Is What You Get) of the page and
allows for graphical editing and creation of the layout of items on the page.
This graphical editing is particularly useful when it comes to such things as
laying out tables within tables, perhaps where pictures or other graphics are in
use in some of the cells. Since the purpose of any page is for somebody to look
at it, being able to look at it while you lay it out is actually quite useful
for all aspects of its design!
HTML is the secret weapon in
the convert the hard-core arsenal! This tab gives you a text editor view of
the raw code that is generating the page. The view uses colors to differentiate
between HTML tags, text, JavaScript code or VB script, webbot code (these
webbots are a part of FrontPage's own page generating weaponry — more about this
later), etc., making it easy to read the code. You can still use all the
graphical editor buttons, such as those to insert a table or a picture. The
difference here is that you see the code inserted instead of the effect on the
page. As far as text editors for HTML or ASP pages go, this one is very near
the top of the heap! If you know your HTML, you can make it do anything you would
like to in this view.
Preview allows for just what
you would expect. FrontPage also has a cool Preview in Browser feature.
Located on the File menu, this feature allows you to select from any of the
browsers installed on the machine and to preset the window size for that
browser. Thus you can check cross browser compatibility as well as checking out
how well your design fits different sized windows.
This gives an idea of the
basic features of FrontPage. Now let's take a look at what it can generate.
Earlier versions of FrontPage
developed a reputation for creating clunky code and for changing elegant
manually created code into code of its own ilk. This feature was long gone by
the time FrontPage 2000 was released. FrontPage now generates quite nice,
concise code and leaves your code alone — as long as you don't mess with its
code! Let me explain — and also uncovered in this explanation is another of the
secret weapons of FrontPage!!
To set a scene: we need to
create a page with a form with fifty or so elements to be filled out by the page
visitor. When the user clicks submit we must validate all the data on the form, and
when it is good, we must send it off to a data file.
If we do this in FrontPage, we
can specify the validation we require on each form field and FrontPage attaches
a webbot detail to the field describing the required validation (take a look
at the HTML view of the page). It also adds code to the form definition tags
like this:
action="--WEBBOT-SELF--"
onsubmit="return FrontPage_Form1_Validator(this)" name="FrontPage_Form1"
This will invoke the
validator to check all the input fields according to our defined validation
requirements. The trick is how it does it!
Use the Preview in Browser
to look at the page, right click on it and View Source. You can now see all
the code as provided to the client browser (by default, you'll be looking at it
in Notepad). Look at all that sweet JavaScript code! As the onsubmit code
above would suggest, the validation is actually being performed by this
generated JavaScript.
Here's the catch: since this
code was generated by FrontPage, it feels it owns the code so if you try to
copy it into place in the original page and tweak it a little, the next time
FrontPage looks at the page, it will undo your tweaks. No problem! Suppose you
want to add validation such that if this field is checked, these three must be
populated and this must be numeric, in other words validation for one field
dependant of the value of another. This would require adding if statements
and other bits of JavaScript to the validation routine. Heres what you do:
use FrontPage to generate all the validations you can, using the above described
method. Copy and paste the code into your original page. Change the name
of the validation routine, both on its function statement and where it is
invoked on the Form statement. Change the name of the form itself.
Remove all the
<!--webbot bot="Validation" --> tags from the body of the form. Don't miss
any — this is important!
Notice also that
when you add the Send to File Name and Email option to the Form Properties,
FrontPage generates a <!--webbot bot="SaveResults" > tag under the Form tag.
Leave this one alone if you still want to save your results. All that JavaScript is now yours, tweak it as you
will, FrontPage will leave it alone!
Changing the name of the form
was important, because if it sees its generated name and there is no longer any
webbot validation, etc. in the form, FrontPage will remove the name from the
form altogether and you may well need that somewhere. The form name is not used
to identify the fields in the form since the generated validation routine use
theForm as a form name and is called with the this keyword. Similarly,
changing the name of the routine prevents FrontPage from presuming that it still
owns the code. While earlier versions of FrontPage would change pretty much
anything they wanted to, 2000 onwards leaves your code alone.
This explanation seems a
little long winded, but if you try it you will find you can create very
sophisticated code simply and quickly, using the base of code generated by
FrontPage. Also, hunt around in the program -- there are other treasures to be
unearthed!
FrontPage has a rich feature
set, and when you consider that it can look like a WYSYWIG generator and an HTML
text editor at the same time, allows for easy previewing and can generate tons of
useful code for you, it becomes a product worth a look, even for the most hard
core coders! Productivity rules! More, Better, Faster are the words of the
day and in this light I think we can use all the help we can get. There is no
doubt for me that FrontPage belongs in my toolbox. It sits near the top because
I pull it out often!
| 
IE 7
Firefox 2.0
