Bitspot Web Application Design Guidelines

Every programmer develops habits, a sense of style, and routines to make his life easier. When it comes to creating PHP web applications, here are mine. Comments welcome.

This is recorded here in rough from my old, private journal. I'll pretty it up later.

20041003

BITSPOT web application development specification/guidelines:

  • global.inc.php should be included in [document].php, prior to output
  • header.inc.php should NOT be included in [document].php, prior to output; it will be called by global.inc.php
  • footer.inc.php should be included in the [document].php
  • global.inc.php should ob_start() to allow for header() calls in [document].php, or in [document].inc.php.
  • global should include header.inc.php, then output and clear any messages stored in the user's cookie session,
    • then [document].inc.php,
    • then flush().
  • [document].inc.php will contain any function calls, input validation and database update/insert operations specific to [document].php
  • [document].inc.php may use a 302 redirect to an appropriate page (typically itself) upon completion of any db editing operation to insure it occurs only once, and can't be repreated through a browser refresh/reload. all browser POST method operations should use a 302 redirect.
  • [document].inc.php may output messages resulting from its operations directly,
  • [document].inc.php may store messages resulting from its operations in the user's session variables in preparation for a 302 redirect. (for output later - see messages above)

global.inc.php should contain a cookie detector, to help deal with or warn users with cookies turned off.

shop guidelines: "carts" are built and recorded in the database in realtime; carts not placed as orders timeout periodically (or are stored for study). Authorize.net is the payment processor of choice; charge architecture should be modular. UPS is the shipper of choice; shipping cost calculation architecture should be modular. all transaction submissions should be 302 redirected to prevent dupe submits. gpg should be used to encrypt and store all cc submissions (submitted over ssl).

any php document shall end in .php[3/4] or .html, NOT .inc, .ihtml, .module, .theme nor any other extension.

where practiceable, header/footer/navbar/other components should be included using comment markup into an single valid xhtml document, and parsed on the fly. header.inc.php and footer.inc.php should simply have stub code that opens and parses the full template file. This way, apps like nvu will have minimum difficulty parsing the template and saving edits.

20050823

an idea for adding to bitspot web app design guidelines/specifications: when creating form elements with array names (eg, "some_field[]"), enumerate the key using the value of primary key field for the table.

MySQL db design

  • always have a primary key
  • use human readable indexes where possible

db.inc.php

  • when using ht2tab(), always make sure you put an index variable in the form inputs to match up records. do not just use name="name[]" and hope it matches up. The id does not even have to match actual record's primary key value.

CommentsNato Welch 2006/01/14 08:53

bitspotwebapps.txt · Last modified: 2006/03/29 15:06 by nato
Recent changes RSS feed Creative Commons License Donate Driven by DokuWiki