Mac Newbold mac at macnewbold.com
Wed Nov 10 13:28:01 MST 2004

Yesterday at 7:21pm, Steven Retz said:

>I have been reading the book I got, "Advanced PHP Programming".  I
>have been wondering what the members of the group are doing for
>templates, either smarty, ad hoc, or some other way.

I guess you'd call what I do "ad-hoc", but really it's just following
basic principles that any programmer (no matter what language) should
know. I think there are just a few main principles that if applied
properly can dramatically reduce your need for a "framework", "template
system", or the like.

Principle #1:
Proper code reuse (here I'm talking within a single project)

The basic idea: if the code will be run more than about 3 times in
substantially the same form (i.e., relatively few special cases), then it
should be properly reused rather than copy-and-paste reused. This means it
should be in an include file, a function, a loop, or something similar.
Other reasons to separate things into include files is to isolate changes
(great if you've got multiple developers), increase code clarity (i.e.
remove "bulk" from your files that makes them harder to read), or to get a
finer granularity for reuse.

Following that principle, I get most of my basic "ad-hoc" framework for
the majority of the projects I do:

1) funcs.php - a basic function library, customized for the project

2) defs.php - basic "constants" and configuration, and some globals
   - include(funcs.php)

3) header.php - set up and print out the html header (nav/menu, etc.)
   - include(defs.php)
   - html loads external style sheet

4) body files - all the pages - has the content specific to that page
   - include(header.php), or for small popup windows, include(defs.php)
   - include(footer.php)

5) footer.php - the last part of the html - trailer of the html pages

All of that comes from Principle #1. Then inside each file, there is
another principle that helps to keep things well organized:

Principle #2:
Separate logic and display appropriately

(IMHO, some frameworks take this to the extreme, which isn't appropriate,
and often is more hinderance than help.)

Within a file, put your logic in one place (like the top of the file), and
your display somewhere else (usually the bottom, since it requires the
results of the logic). Organize it like you have ADHD, or a really small
editor window: Pretend like you can't follow the flow of logic over more
than 5-10 lines of display, and vice-versa. So "display logic" can go with
the display, if necessary, but only if it's really short. And big sections
of display shouldn't be intermixed with the code. It's as simple as that.
Often it means you set up variables at the top that get printed out below
by the display code, very similar to the way that Smarty templates set up
smarty vars, but without all the different syntax.

I can't think of any other major "guiding principles" that I use, although
there might be some. Everyone is welcome to poke fun, tell me I'm wrong,
give alterate suggestions, educate me, or any combination of the above. :)


Mac Newbold		MNE - Mac Newbold Enterprises, LLC
mac at macnewbold.com	http://www.macnewbold.com/

More information about the UPHPU mailing list