Techniques and tips for writing scripts
Position of scripts
It is standard
practice to put scripts in the Head section of your document, but the
Page view in the HTML editor does not handle scripts in the Head
section. To author and debug scripts in Page view, you should put
scripts at the beginning of the Body section.
In addition:
- Scripts are not allowed
within a TEXTAREA or SELECT tag - There are restrictions for server scripts that
build client scripts - There are restrictions for server scripts embedded
in client scripts
Balanced HTML that the editor can understand
Page view in
the HTML editor requires valid HTML. So if you use a script to build
part of an element and use straight HTML for the rest of the element,
the editor will have trouble displaying the page containing the
element in Page view. If you use the debugger, you will not want
to avoid Page view, so make sure the HTML on your page is balanced.
Start and finish an element in HTML or start and finish it in a
script, but do not start in one mode and finish in the other.
For example, if a script is providing data for a table, you
might consider it easier to code the table’s heading row
in HTML and then include a script for the data. To take advantage
of the editor and debugging, it would be a better choice to create
the heading row in the script too, even if it seems like a little more
work.
A similar situation occurs when you include a script inside
an element when Page view expects only text. For example, you cannot
successfully include a script inside a SELECT element in a form.
Instead, write the script so that it generates the SELECT start
and end tags too.
Example
This does not work in Page view:
|
1 |
<FORM> |
|
1 |
<SELECT> |
|
1 |
<SCRIPT>...</SCRIPT> |
|
1 |
</SELECT> |
|
1 |
</FORM> |
Instead, do this:
|
1 |
<FORM> |
|
1 |
<SCRIPT> |
|
1 |
psDocument.Write("<SELECT>"); |
|
1 |
... |
|
1 |
psDocument.Write("</SELECT>"); |
|
1 |
</SCRIPT> |
|
1 |
</FORM> |
Server scripts that build client scripts
If a server script
creates a client script, the debugging interface in the editor will not
know anything about the client script, since it does not exist in
the page the editor sees. There are certainly no restrictions
on building scripts this way, but be aware that you will not be
able to debug the client script. You can debug the server script
to make sure it is creating the client script correctly.
Server scripts embedded in client scripts
A Web target does
not provide support for server scripts that you embed in client
scripts. This restriction applies to the HTML editor, Script editors,
object model, debugger, and deployment controllers.
However, server scripts that you write in the native object
model of a particular application server (such as PowerDynamo or
ASP) remain intact. This means that you can write these native server
scripts in the editor’s Source view and deploy the resulting
files to the corresponding application server. The deployment controller
will deploy those scripts exactly as you have coded them.
URLs in scripts
A Web target manages links in
HTML pages. It remaps the URLs according to the directory structure
of the target or deployed site. However, a Web target cannot manage
URLs in scripts the way it manages URLs in HTML attributes. Therefore,
when you build URLs dynamically in a script, use methods provided
in the Web Target object model to get information about the server and
directory structure so that the URLs reflect the current environment.
The following methods belong to psDocumentClass and can be
used to build a URL dynamically:
- File()
- FileExtension()
- Path()
- Site()
Example
To build an URL, your script might include code like this:
|
1 |
"http://" + psDocument.Site() + "/" + filefortoday + ".htm"; |