Use lower case with MySQL. Lower name databases, tables, and columns. This keeps everything simple and you’ll never need to guess whether something is upper case or lower case or a mixed case. Also, on systems that treat “file.db” differently than “File.db”, lower case everything saves a great deal of headaches.

In every single table you have, make your first column “id”. Make it a primary key, auto-incrementing, integer. This keeps things very clean when you need to positively identify records and make changes or deletions. It also works great with the save function and object code as previously mentioned.

When referencing other tables within your system, make their column names “id_[remote_table]”.  When referencing id values from other systems outside of yours, make them “[outside_system]_id”.  This makes it easy to see whether you’re referencing something internally or externally.

August 28th, 2013

Posted In: Basics, Database

Leave a Comment

Just like the posting on where to put CSS, javascript functions in a similar way.

Javascript can be written in .js files or included dynamically on the page via <script> tags or even on an item-by-item basis with things like “onclick=’doStuff()'”.

If you have certain functions or variables you need to have always available and globally accessed, put them in a shared .js file that is included on every page.  This is a great way to handle some basic Ajax calls and some other shared code that is used frequently.

If you have forms that have custom requirements before submitting, include that code right in the PHP file you’re working on as a part of the visual part of your command structure.  This will make debugging easier and you can dynamically generate that form verification based on logic that PHP knows about (such as which form elements should or should not be included based on various conditions).

Sometimes you just need to do a really simple something that is unique on a per element basis: Go ahead and add javascript right into your element as needed.  Makes it easy to debug and there’s no reason to make things more complicated than you need to.

DO NOT put all of your javascript into .js files just because you think you should.  There’s no good reason to.  Instead, look at where they fit best on their own.  Some javascript may need to be dynamically generated by PHP.  Having a static .js file is incompatible with this concept.

August 28th, 2013

Posted In: Basics

Leave a Comment

When working on the visual elements of your design, where do you put the CSS?

Should you have one global stylesheet that contains all CSS for your entire project? (Some people do this.)

Should you have a couple stylesheets that are generally always included that cover everything?

Should you just write all of your CSS inline, right in the DIV and P tags?

Should your CSS be written on a page-by-page basis and be included in style tags on the page?

Answer: Some mixture of all of the above.

Your global stylesheet should be used only to define the basic look and feel of your entire system. It should not contain anything that will be used only once. Everything in that global sheet should be used repeatedly and excessively throughout your system.

Your individualized stylesheets should be used for sub-systems that share a variety of page displays and have a unique set of attributes or visual design that build upon or enhance the global stylesheet.

Individual CSS attributes can be applied to DIV, P, SPAN, and other tags for individually unique items. Likewise, you should use the style tag and include CSS information within that style tag on a per-page basis if that page shares the same CSS on multiple copies of items within the page.

DO NOT build your system with just one global stylesheet and dump everything into it. It’s a disaster waiting to happen. Plus, every time you make any change, your clients need to do a force-refresh to get the new stylesheet. “Where’s the new style?” “Press force-refresh to get it.” “How are users supposed to know they need to do that?” “Uhm…”

DO NOT write the same style into a style tag on everything. If you find yourself copy-pasting a ton of code, something’s wrong.

Use dynamically-generated CSS when and where applicable to suit your application’s needs. Sometimes you have to write your CSS on individual object items because that’s the only way to make them do exactly what you need them to do. That’s OK.

August 28th, 2013

Posted In: Basics

Leave a Comment

You should never, under any circumstance, be writing in your code more than once.

Use a header file. Call it what you want, I like ‘header.php’ or ‘header.inc.php’ and have it handle all those things.

Your code should look something like this:

<?php

// Author
// Test URL
$page_title = "Ad Edit";
$useCKeditor = true;
include 'header.php';

$command = $_REQUEST['command'];

if($command=='something) {
...

You should also never be writing more than once. That should be in a footer file. Continuing the above example:


if($command=='something_else') {
...
}

include 'footer.php';
?>

In your header you should include your common file as well as any files necessary for view-based pages. You should also have boolean options for disabling navigation and other items that aren’t necessary when performing ajax calls so you can continue to use your header for those fun things. Your footer should also have an option to not display itself (preferably inheriting the same variable as the header) and in general shouldn’t be trying to do too much.

August 20th, 2013

Posted In: Basics

Leave a Comment

When naming files or variables, use underscores or at least alternating cases as appropriate.  Do not just omit all spaces and capitalization, it makes it terrible to work on later.  Also, remember that computers have lots of memory these days and using an extra couple characters in variable name can make life so much easier down the road.

Examples filenames:

adcostperrecruiter.php vs ad_cost_per_recruiter.php
or
clientcontacthitlist.lasso vs client_contact_hitlist.lasso
or
clientjqrefquestionsnext.lasso vs client_jq_refQuestions_next.lasso

Example variables:

$cltid; // I think this means “client id”
$coname; // I think this means “company name”
$cname; // I think this means “contact name”
vs
$hideTitleInfo;
$useAjax;
$autoDisplayTabs;

Just think about it this way – if you come back to your own code 6 months later, will you be able to read what you wrote?

August 12th, 2013

Posted In: Basics

Leave a Comment

I’m a fan of procedurally based controllers.  They make sense, they use less memory, run faster, are easier to debug, and most importantly, are easier and faster to create.

Let’s say you have a user-account page.  It allows the user to change his/her email address, password, physical address and other similar parameters.  I’m going to assume the file structure looks something like this:

  • my_account.php
  • my_account_save.php
  • account_class.inc.php

Using the command structure, let’s assume that my_account.php has basically one command, it lets the user view their own account details and shows those details in a <form> view.  The my_account_save.php page accepts inputs from my_account.php and tells the model, account_class.inc.php, what to do with them.

If you’re using an object-based controller, your files might look like this:

  • my_account.php
  • controller.inc.php
  • account_controller.inc.php
  • account_class.inc.php

In the procedural version of this code the my_account.php and my_account_save.php are very closely linked.  The fieldnames in my_account.php are used in my_account_save.php and tell the model what data to put where.  It then tells the model to save its work and bring the user back to the my_account.php page with any notifications necessary.

In the object oriented version of this system, the controller.inc.php page must determine what kind of input is coming in from which system (excess code), then spin up a copy of the correct controller object and pass the form variables to it.  The controller must then decide what action is being done (setting email, resetting a password?) and then take appropriate action.  It then returns results or failures back to the controller.inc.php file which then needs to know to redirect the user back to my_account.php with successes or failures.

Besides having the extra (unnecessary) layer of abstraction in the object-based system, I also don’t like that form variables that are created in my_account.php are tied so tightly to the account_controller.inc.php.  If you’re going to be abstracting your code out, then you need to be passing each layer copies of the data, modeling into whatever format the next layer up (or down) is expecting.  In many cases, that’s just excess work for what you actually need to do to get the project done and creates more code than is necessary.  More code equals more bugs and more time.

March 29th, 2013

Posted In: Basics

Leave a Comment

For my very first post on this site, I’d like to introduce “The Command Structure.”

This is a pretty simple idea.  Anywhere your code has to do something or trigger something else to happen, there’s an explicitly stated “command” that is passed.  With that command, it’s easy to search or hop to certain parts of code to find what is going on.  It also separates code into nice easy-to-read and easy-to-understand segments.

Most of my programming examples will be in PHP.  It’s a popular, open source language, and it’s fast and stable.  Are other languages faster?  Probably.  Are other languages as widely used?  Sure.  PHP is mature, widely used, and easy to work with, therefore I love it.

Let’s say you have a simple PHP page that asks users to submit a form and you’re going to store the resulting data in a database.  Here’s how the command structure would work with that page:

<?php

include 'header.inc.php';
$command = $_REQUEST['command'];

if($command=='') {
	?>
		// display page, with form here
		<form action="<?=$_SERVER['PHP_SELF']?>" method='post'>
		<input type='hidden' name='command' value='save'>
		<input type='text' name='my_text_input_field'>
		<input type='submit' value='Save'>
		</form>
	<?
}

if($command=='save') {
	$query = "INSERT INTO ... SET `fieldname`='".mysql_real_escape_string($_REQUEST['my_text_input_field'])."'";
	mysql_query($query);
	header("Location: ".$_SERVER['PHP_SELF']."?command=thank");
	exit;
}

if($command=='thank') {
	echo "Thank you for adding data to our database";
}

include 'footer.inc.php';

?>

So this is obviously a rough example, but it’s easy to see how on one page you can handle multiple operations, and it’s easy to see what is going to happen when, where, and how. And for those of you keeping track at home, you’re probably shouting, “Hey, that’s not even MVC code!” And you’re right, technically it isn’t. There’s no model at all, and the controller and view are in the same file. That’s OK for now, I’m just illustrating a basic programming point before moving on to more advanced topics.

In the future I’ll be covering how to handle object creation, writing to databases, user input requirements, and more.

March 27th, 2013

Posted In: Basics

Leave a Comment