Cgiapp 1.5 has been released; you may now download it.
This release fixes a subtle bug I hadn't encountered before; namely, when a
method name or function name is passed as an argument to mode_param()
, run()
was receiving the requested run mode… and then attempting to process that as the
mode param. The behaviour is now fixed, and is actually simpler than the
previous (non-working) behaviour.
Also, on reading Chris Shiflet's paper on PHP security, I
decided to reinstate the query()
method. I had been using $_REQUEST
to check
for a run mode parameter; because this combines the $_GET
, $_POST
, and
$_COOKIE
arrays, it's considered a bit of a security risk. query()
now
creates a combined array of $_GET
and $_POST
variable ($_POST
taking
precedence over $_GET
) and stores them in the property $_CGIAPP_REQUEST
; it
returns a reference to that property. run()
uses that property to determine
the run mode now.
Enjoy!
I've been playing with parameter testing in my various Cgiapp classes, and one test that seemed pretty slick was the following:
if (!array_key_exists('some_string', $_REQUEST)) {
// some error
}
Seems pretty straight-forward: $_REQUEST
is an associative array, and I want
to test for the existence of a key in it. Sure, I could use isset()
, but it
seemed… ugly, and verbose, and a waste of keystrokes, particularly when I'm
using the param()
method:
if (!isset($_REQUEST[$this->param('some_param')])) {
// some error
}
However, I ran into a pitfall: when it comes to array_key_exists()
,
$_REQUEST
isn't exactly an array. I think what's going on is that $_REQUEST
is actually a superset of several other arrays — $_POST
, $_GET
, and
$_COOKIE
— and isset()
has some logic to descend amongst the various keys,
while array_key_exists()
can only work on a single level.
Whatever the explanation, I ended up reverting a bunch of code. :-(
I've standardized my PHP programming to use the environment variable
SCRIPT_NAME
when I want my script to refer to itself in links and form
actions. I've known that PHP_SELF
has the same information, but I was more
familiar with the name SCRIPT_NAME
from using it in perl, and liked the feel
of it more as it seems to describe the resource better (PHP_SELF
could stand
for the path to the PHP executable if I were to go by the name only).
However, I just noticed a post on the php.general newsgroup where somebody asked
what the difference was between them. Semantically, there isn't any; they should
contain the same information. However, historically and technically speaking,
there is. SCRIPT_NAME
is defined in the CGI 1.1 specification, and is thus a
standard. However, not all web servers actually implement it, and thus it
isn't necessarily portable. PHP_SELF
, on the other hand, is implemented
directly by PHP, and as long as you're programming in PHP, will always be
present.
Guess I have some grep and sed in my future as I change a bunch of scripts…
Occasionally, I've needed to process a lot of information from a script, but I don't want to worry about PHP timing out or the user aborting the script (by clicking on another link or closing the window). Initially, I investigated register_shutdown_function() for this; it will fire off a process once the page finishes loading. Unfortunately, the process is still a part of the current connection, so it can be aborted in the same way as any other script (i.e., by hitting stop, closing the browser, going to a new link, etc.).
However, there's another setting initialized via a function that can override this behaviour — i.e., let the script continue running after the abort. This is ignore_user_abort(). By setting this to true, your script will continue running after the fact.
This sort of thing would be especially good for bulk uploads where the upload needs to be processed — say, for instance, a group of images or email addresses.
In the past two days, I've seen two references to Practical PHP Programming, an online book that serves both as an introduction to programming with PHP5 and MySQL as well as a good advanced reference with many good tips.
This evening, I was browsing through the Performance chapter (chapter 18), and
found a number of cool things, both for PHP and MySQL. Many were common sense
things that I've been doing for a while, but which I've also seen and shaken my
head at in code I've seen from others (calculating loop invariables at every
iteration, not using variables passed to a function, not returning a value from
a function, not using a return value from a function). Others were new and gave
me pause for thought (string concatenation with the '.' operator is expensive,
especially when done more than once in an operation; echo
can take a comma
separated list).
Some PHP myths were also dispelled, some of which I've been wondering about for awhile. For instance, the amount of comments and whitespace in PHP are not a factor in performance (and PHP caching systems will often strip them out anyways); double quotes are not more expensive than single quotes unless variable interpolation occurs.
It also has some good advice for SQL optimization, and, more importantly, MySQL
server optimization. For instance, the author suggests running OPTIMIZE TABLE table;
on any table that has been added/updated/deleted from to any large
extent since creation; this will defrag the table and give it better
performance. Use CHAR()
versus VARCHAR()
; VARCHAR()
saves on space, but
MySQL has to calculate how much space was used each time it queries in order to
determine where the next field or record starts. However, if you have any
variable length fields, you may as well use as many as you need — or split off
variable length fields (such as a TEXT()
field) into a different table in
order to speed up searching. When performing JOIN
s, compare on numeric fields
instead of character fields, and always JOIN
on rows that are indexed.
I haven't read the entire book, but glancing through the TOC, there are some potential downfalls to its content:
Mail
and Mail_MIME
, DB
), but in
the examples rarely uses them.All told, there's plenty of meat in this book — I wish it were in dead tree format already so I could browse through it at my leisure, instead of in front of the computer.
I've had a few people contact me indicating interest in Cgiapp, and I've noticed
a number of subscribers to the freshmeat project I've setup. In addition, we're
using the library extensively at the
National Gardening Association in developing our new
site (the current site is using a mixture of ASP and Tango, with several newer
applications using PHP). I've also been monitoring the CGI::Application
mailing list. As a result of all this activity, I've decided I need to develop a
roadmap for Cgiapp.
Currently, planned changes include:
Version 1.x series:
stripslashes
(the Smarty "function" call will be sslashes
).param()
bugfix: currently, calling param()
with no arguments simply
gives you a list of parameters registered with the method, but not their
values; this will be fixed.error_mode()
method. The CGI::Application
ML brought up and implemented
the idea of an error_mode()
method to register an error_mode
with the
object (similar to run_modes()
). While non-essential, it would offer a
standard, built-in hook for error handling.$PATH_INFO
traversing. Again, on the CGI::App
ML, a request was brought
up for built-in support for using $PATH_INFO
to determine the run mode.
Basically, you would pass a parameter indicating which location in the
$PATH_INFO
string holds the run mode.Version 2.x series:
Yes, a Cgiapp2 is in the future. There are a few changes that are either necessitating (a) PHP5, or (b) API changes. In keeping with PEAR guidelines, I'll rename the module Cgiapp2 so as not to break applications designed for Cgiapp.
Changes expected include:
Inherit from PEAR. This will allow for some built in error handling, among
other things. I suspect that this will tie in with the error_mode()
, and
may also deprecate croak()
and carp()
.
Changes to tmpl_path()
and load_tmpl()
. In the perl version, you would
instantiate a template using load_tmpl()
, assign your variables to it,
and then do your fetch()
on it. So, this:
$this->tmpl_assign('var1', 'val1');
$body = $this->load_tmpl('template.html');
Becomes this:
$tmpl = $this->load_tmpl();
$tmpl->assign('var1', 'val1');
$body = $tmpl->fetch('template.html');
OR
$tmpl = $this->load_tmpl('template.html');
$tmpl->assign('var1', 'val1');
$body = $tmpl->fetch();
(Both examples assume use of Smarty.) I want to revert to this behaviour for several reasons:
Portability with perl. This is one area in which the PHP and perl versions differ greatly; going to the perl way makes porting classes between the two languages simpler.
Decoupling. The current set of template methods create an object as a parameter of the application object — which is fine, unless the template object instantiator returns an object of a different kind.
Cons:
Smarty can use the same object to fill multiple templates, and the
current methods make use of this. By assigning the template object
locally to each method, this could be lost. HOWEVER… an easy
work-around would be for load_tmpl()
to create the object and store
it an a parameter; subsequent calls would return the same object
reference. The difficulty then would be if load_tmpl()
assumed a
template name would be passed. However, even in CGI::App
, you decide
on a template engine and design for that engine; there is never an
assumption that template engines should be swappable.
Existing Cgiapp1 applications would need to be rewritten.
Plugin Architecture: The CGI::App
ML has produced a ::Plugin
namespace that utilizes a common plugin architecture. The way it is done
in perl is through some magic of namespaces and export routines… both of
which are, notably, missing from PHP.
However, I think I may know a workaround for this, if I use PHP5: the
magic __call()
overloader method.
My idea is to have plugin classes register methods that should be
accessible by a Cgiapp-based class a special key in the $_GLOBALS
array.
Then, the __call()
method would check the key for registered methods; if
one is found matching a method requested, that method is called (using
call_user_func()
), with the Cgiapp-based object reference as the first
reference. Voilá! instant plugins!
Why do this? A library of 'standard' plugins could then be created, such as:
tmpl_*
methods)Since the 'exported' methods would have access to the Cgiapp object, they could even register objects or parameters with it.
If you have any requests or comments on the roadmap, please feel free to contact me.
The new weierophinney.net/matthew/ site is now up and running!
The site has been many months in planning, and about a month or so in actual coding. I have written the site in, instead of flatfiles, PHP, so as to:
I've written it using a strict MVC model, which means that I have libraries for accessing and manipulating the database; all displays are template driven (meaning I can create them with plain-old HTML); and I can create customizable applications out of various controller libraries. I've called this concoction Dragonfly.
There will be more developments coming — sitewide search comes to mind, as well as RSS feeds for the blog and downloads.
Stay Tuned!
On PhpPatterns, I recently read an article on Template Engines in PHP. It got my ire up, as it said (my interpretation):
Okay, so that's actually direct quotes from the article. I took issue with it, immediately — I use Smarty for everything I do, and the decision to do so was not done lightly. I have in fact been advocating the use of template engines in one language or another for several years with the various positions in which I've been employed; I think they are an essential tool for projects larger than a few pages. Why?
So, reading the aforementioned article really got my hackles up. However, it got me thinking, as well. One issue raised is that PHP can be used as your templating language. While I can understand why this might be desirable — everything from load issues to flexibility — I also feel that this doesn't give enough abstraction.
Using PHP seems to me to be inefficient on two fundamental levels, based on my understanding of The Pragmatic Programmer:
The author of the article also makes a case for teaching web designers PHP — that the language is sufficiently easy to pick up that they typically will be able to learn it as easily, if not more easily, than a template language. I agree to a degree… But my experience has shown that web designers typically struggle with HTML, let alone PHP. (Note: my experience in this regard is not huge, and I'm sure that this is an exaggeration.) I find that it's typically easiest for me to give an example template, explain what the funny, non-HTML stuff can do, and let them go from there. Using this approach, they do not need to learn anything new — they simply work with placeholders.
Still, I think the author raises some fine points. I wish he'd bothered to do more research into why people choose template engines and the benefits that arise from using them before simply outright slamming them. Of course, the article is also a bit dated; it was written over two years ago, and much has changed in the world of PHP and many of its template engines. I'm curious as to whether they would feel the same way today.
Me? My mind is made up — the benefits, in my circumstances, far outweigh any costs associated. I'll be using template engines, and Smarty in particular, for years to come.
After working on some OO classes yesterday for an application backend I'm
developing for work, I decided I needed to create a BREAD
class to make this
simpler. You know, Browse-Read-Edit-Add-Delete.
At first, I figured I'd build off of what I'd done yesterday. But then I got to
thinking (ah, thinking, my curse). I ran into the BREAD
concept originally
when investigating CGI::Application
; a number of individuals had developed
CGI::Apps
that provided this functionality. I'd discarded them usually because
they provided more functionality than I needed or because they introduced more
complexity than I was willing to tackle right then.
But once my thoughts had gone to BREAD
and CGI::App
, I started thinking how
nice it would be to have CGI::Application
for PHP. And then I thought, why
not? What prevents me from porting it? I have the source…
So, today I stayed home with Maeve, who, on the tail end of an illness,
evidently ran herself down when at daycare yesterday, and stayed home sleeping
most of the day. So, while she was resting, I sat down with a printout of the
non-POD code of CGI::App
and hammered out what I needed to do. Then, when she
fell asleep for a nap, I typed it all out and started testing. And, I'm proud to
say, it works. For an example, visit
my development site to see a
very simple, templated application in action.
I was lamenting at work the other day that now that I've discovered OO and templating with PHP, the only major feature missing for me is a way to easily document my programs. I'm a big fan of perl's POD, and use it fairly extensively, even for simple scripts — it's a way to provide a quick manual without needing to worry too much about how to format it.
So, it hit me on the way home Friday night: what prevents me from using POD in multiline comments of PHP scripts? I thought I'd give it a try when I got home.
First I googled for 'POD for PHP', and found a link to perlmongers where somebody recounted seeing that exact thing done, and how nicely it worked.
Then I tried it… and it indeed worked. So, basically, I've got all the tools I love from perl in PHP, one of which is borrowed directly from the language!