Contents

University Web Services

Best Practices

Scripts and Databases

The only server-side languages available are ASP and php.

Procedures

If a script needs to write to a file, that script must reside on a special server. IOW, no writing to a file on our main public server.

Databases

Normalize your database

Also, if working with large datasets, it's preferable to use SQL database, even when XML might be required, since data can be used from database to create XML files.

Don't store binary data in the database.

Stick to one database/table/field naming scheme.

Usability

If Javascript is used, the page must still function if Javascript is turned off

When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

Organization of Code

Separate code from content

Follow a standard model of organization. Here's a suggested one:

In general, you should follow the standards found in the PEAR manual: http://pear.php.net/manual/en/standards.php

Security and All That

Any time a script is written, security becomes an issue because potentially that script can be used as a doorway for hackers to enter the University's information systems. For this reason, all scripts should be reviewed by OIT prior to implementation, and all scripts should be reviewed by OIT any time they are revised.

Any script and/or form that requests personal or medical information is subject to Federal and State law, including HIPAA and FERPA. It is the responsibility of the developer to know the risks.

Other

Validate the page after the script has run to make sure you are producing valid output.

pick a naming scheme and stick with it for every script.

Program scripts with security in mind. Filter and parse all incoming data from the web for vulnerabilities.

Have a plan or logicflow chart for scripts before design.

Document and comment all scripts so that if somebody new opens it - they would be able to understand what is going on.

Here is our script library: