navigation  interaction  search

 other resources

Coding Style

phpBMS strives to use concise and and consistent terms when coding. Unfortunately, not all of the current phpBMS code itself lives up to these standards. As the phpBMS project evolves, the code will comply as strictly as possible to these standards. Newly contributed code should always follow the standards set here.

Because phpBMS utilizes several languages (programming and otherwise) we have broken down the styles into different areas, one for each language.

PHP

Because of the ease of use and learning PHP, coding styles can vary widely or sometimes be non-existent. As stated above, some legacy code of phpBMS may not strictly adhere to these styles, but wherever possible, especially in any newly submitted code some basic styles that we try to following.

Functionality belongs in the included files

Wherever feasible, try to put the "logic" processing of a PHP template in an included file, and typically as a function. Then in the main template, you need only call the function , or reference the object.

Functions names should be descriptive, and should follow a "title case" one word format. For instance, if you have a function that compounds interest on an invoice, you would define the function like

  function compoundInterest($invoiceid,$dblink){

Variables

Variable names should be one word (no hyphens) and try to remain lowercase. If the lowercase name is too long, or hard to understand, using the title-case, one-word convention similar to functions is preferred. As with function names, use descriptive names, and not one letter names, or abbreviations that are cryptic.

Try to avoid referring, _POST, or _GET variables *inside* the functions themselves. It is better to pass them, either en masse, or individually to the appropriate function.

Adhere to PHP installed defaults functionality

If you plan on releasing a modules, or want your code to be included in the phpBMS core, make sure you do not reference PHP functions that are not installed on default PHP installs. For instance, the latest version of PHP does not ship with PEAR functionality, so do no make and PEAR function calls from. The only external library we reference, FPDF, we happen to also include in the install of the program.

To Object-Orient or not to Object Orient

This option is entirely up to you. Although most of phpBMS is not programmed using objects, some of the more complex pieces of functionality are. Generally, we recommend maintaining the status quo - if a section is mostly programmed using objects, try to stick with them.

When making database calls inside a function, make sure to pass the database link ($dblink) instead of having to declare it global in the function itself. Parts of phpBMS are still notorious for not doing this, but we are trying to convert those over when possible.

Error Reporting

Whenever feasible, code to catch as many errors as possible. Then, use the reportError function to display it properly.

JavaScript

JavaScript files are all located in either in the /common/javascript directory - for files used in many places, or in a modules javascript/ directory. If you add javascript functionality to a js file in the /common/javascript directory, the indication is that you want those files included in the phpBMS core. If you have code specific to a single page, place it a js file in the modules javascript directory. Have the name of the js file reflect the same base name as the file calling it. For instance, the invoice_addedit.php file references the javascript/invoice.js file for any javascript functions specific to this screen.

Function and Variable Names

JavaScript follows the same naming conventions and general coding styles as PHP. Although JavaScript is a looser language than PHP, try to add semi-colons at the end of all statements.

Passing Variables from PHP to JavaScript using AJAX

There are two mechanisms for sharing data between PHP and javascript. The most evident is the AJAX calls that JavaScript makes. Typically this references a PHP file that returns data in an XML format. As well, most of these calls, while asynchronous from the initial page load are not asynchronous from the Javascript using the AJAX call. Because of this, make sure you code in loading graphics or indicators

Passing Variables from PHP to JavaScript using jstransport.php

In addition to making AJAX calls, phpBMS can pass information from PHP to javascript using the jstransport.php file, and the $_SESSION["include_js"] variable. You can add any javascript code to the $_SESSION["include_js"] variable, and it will be appropriately processed as javascript code. This is useful for sending application information (such as date format) to javascript.

XHTML

phpBMS uses XHTML standards (rather than basic HTML standards). In short terms, if you are familiar with HTML but not XHTML, there are a couple of times you will want to make sure to implement.

Terminate tags

If you have a <p> tag, make sure, there is a corresponding </p> tags. Tags that do not have a corresponding closing tag should have the closing slash inside the tag itself (<br> becomes <br />, <img> becomes <img />

Format Tag Properties Properly

Tag properties should always be declared in lower case, and always have a value, surrounded by quotations.

Unacceptable property declarations

  <input checked />
  <button onClick="callFunction()"></button>
  <td align=right></td>

Acceptable property declarations

  <input checked="checked" />
  <button onclick="callfunction()"></button>
  <td align="right"></td>

For more detailed information on XHTML compatibility, see the W3C

Use Tags Semantically

This seems like a no-brainer, but too often HTML code contains too many tags. Why use multiple <br /> tags or &nbsp; codes to denote padding when it can be done in CSS? Separate paragraphs of information with the <p> (paragraph) tag. This makes for "semantic" markup. If you see "<p>This is some text.</p>" in the code, the use of semantic markup means it is easy to see that the text is a paragraph, and should be formatted as such.

Every tag has a specific use. As an example, <UL> and <OL> tags are for formatting lists of information. Use them as such! And another: do not use <div> tags to separate paragraphs, use <p> tags.

One last evil word: tables. Tables are the most abused part of HTML. Do not use them for formatting and styling. Only use tables if you need to display multiple lies, of multi-columnar information (i.e. "Tabular" data) that needs to line up together.

CSS

All of the core phpBMS style formatting is located in separate CSS files located in /common/stylesheet/{stylename} directory. The default style that ships with the phpBMS core is Mozilla. Styles that are commonly used on multiple pages are stored inside this main directory. Styles that are specific to individual pages are stored in the "pages" sub-directory.

Defining

If a style is used in multiple places (or potentially used in multiple places) on the page, use a class definition. If it is to be used in only one place, use a named definition.

phpBMS Customization CSS

Currently, there is no set standard for CSS that is specific to a phpBMS customization that is not be part of the phpBMS core. We suggest creating a CSS folder in your custom module and creating (or copying) appropriate CSS files inside this directory.

Implementing in XHTML

Avoid defining CSS at the top of an HTML page, or as a property of a tag. If you have a single element that needs formatting, assign it an id, and then used a named CSS definition.

Unacceptable CSS formating:

XHTML file

 <textarea name="foo" style="width:99%"></textarea>

Acceptable CSS formatting:

XHTML file

 <textarea name="foo" id="foo"></textarea>

Included CSS file

 #foo {width:99%}

Implementing in javascript

When practical, it is better to reference classes in javascript rather than explicitly manipulating styles.

Copyright © 2006-2007 Kreotek, LLC. All Rights reserved.