Tag: php
Scrap that. We're gonna' use PHP
I've been researching and coding for a couple months now with the decision that
I'd rewrite the family website/portal using mod_perl
with CGI::Application
.
I still like the idea, but a couple things recently have made me rethink it.
For starters, the perl DBI is a bit of a pain to program. At work, I've become very accustomed to using PEAR's DB library, and while it's in many ways derived from perl's DBI, it's much simpler to use.
Then there's the whole HTML::Template
debacle. There's several ways in which
to write the templates, but they don't all work in all situations, and, it seems
they're a bit limited. We've started using PHP's Smarty at work, and it's much
more intuitive, a wee bit more consistent, and almost infinitely more
extendable. I could go the Template::Toolkit
route for perl, but that's almost
like learning another whole language.
Then, there's the way objects work in perl versus PHP. I've discovered that PHP objects are very easy and very extendable. I wouldn't have found them half as easy, however, if I hadn't already been doing object oriented programming in perl. One major difference, however, is how easy it is to create new attributes on the fly, and the syntax is much easier and cleaner.
Add to that the fact that if you want to dynamically require modules in perl,
you have to go through some significant, often unsurmountable, hoops. So you
can't easily have dynamic objects of dynamically defined classes. In PHP,
though, you can require_once
or include_once
at any time without even
thinking.
The final straw, however, was when I did my first OO application in PHP this
past week. I hammered it out in a matter of an hour or so. Then I rewrote it to
incorporate Smarty in around an hour. And it all worked easily. Then I wrote a
form-handling libary in just over two hours that worked immediately — and made
it possible for me to write a several screen application in a matter of an hour,
complete with form, form validation, and database calls. Doing the same with
CGI::Application
took me hours, if not days.
So, my idea is this: port CGI::Application
to PHP. I love the concept of
CGI::App
— it's exactly how I want to program, and I think it's solid.
However, by porting it to PHP, I automatically have session and cookie support,
and database support is only a few lines of code away when I use PEAR; I'll add
Smarty as the template toolkit of choice, but make it easy to override the
template methods to utilize . I get a nice MVC-style application template, but
one that makes developing quickie applications truly a snap.
This falls under the "right-tool-for-the-job" category; perl, while a wonderful language, and with a large tradition as a CGI language, was not developed for the web as PHP was. PHP just makes more sense in this instance. And I won't be abandoning perl by any stretch; I still use it daily at work and at home for solving any number of tasks from automated backups to checking server availability to keeping my ethernet connection alive. But I have real strengths as a PHP developer, and it would be a shame not to use those strengths with our home website.
PHP Class Tips
We're starting to use OO in our PHP at work. I discovered when I started using it why I'd been having problems wrapping my head around some of the applications I've been programming lately: I've become accustomed in Perl to using an OO framework. Suddenly, programming in PHP was much easier.
There's a few things that are different, however. It appears that you cannot pass objects in object attributes, and then reference them like thus:
$object->db>query($sql)
PHP doesn't like that kind of syntax (at least not in versions 4.x). Instead, you have to pass a reference to the object in the attribute, then set a temporary variable to that reference whenever you wish to use it:
$object->db =& $db;
...
$db = $object->db;
$res = $db->query($sql);
What if you want to inherit from another class and extend one of the methods? In
other words, you want to use the method from the parent class, but you want to
do some additional items with it? Simple: use parent
:
function method1()
{
/* do some pre-processing */
parent::method1(); // Do the parent's version of the method
/* do some more stuff here */
}
Update:
Actually, you can reference objects when they are attributes of another object; you just have to define the references in the correct order:
$db =& DB::connect('dsn');
$this->db =& $db;
...
$res = $this->db->query($sql);
I've tested the above syntax with both PEAR's DB and with Smarty, and it works without issue.
IT hiring principles
I was just reading an article about the Dean campaign's IT infrastructure, and there's an interesting quote from their IT manager, Harish Rao:
"I believe in three principles", he said. "First I always make sure I hire people I can trust 100%. Second, I always try to hire people who are smarter than I am. Third, I give them the independence to do as they see fit as long as they communicate about it to their other team members. We've had a lot of growing pains, a lot of issues; but we've been able to deal with them because we have a high level of trust, skill and communication."
I know for myself that when I (1) don't feel trusted, and/or (2) am not given independence to do what I see as necessary to do my job, I don't communicate with my superiors about my actions, and I also get lazy about my job because I don't feel my work is valued.
Fortunately, I feel that in my current work situation, my employers followed the same principles as Rao, and I've felt more productive and appreciated than I've felt in any previous job.
PHP standards ruminations
I've been thinking about trying to standardize the PHP code we do at work. Rob and I follow similar styles, but there are some definite differences. It would make delving into eachother's code much easier if we both followed some basic, agreed upon, guidelines.
One thing I've been thinking about is function declarations. I find that I'm often retooling a function to make it more general, and in doing so either need to decrease or increase the number of arguments to it. This, of course, breaks compatability.
So I propose that we have all functions take two arguments: $data
and $db
. $data
is a hash which can then be extract
'd via PHP. To change the number of arguments, you can simply set defaults for arguments or return meaningful errors for missing arguments.
Another thought going through my mind deals with the fact that we reuse many of our applications across our various sites, and also export some of them. I think we should try and code the applications as functional libraries or classes, and then place them somewhere in PHP's include path. We can then have a "demo" area that shows how to use the libraries/classes (i.e., example scripts), and to utilize a given application, we need simply include it like: include 'apps/eventCalendar/calendar.inc';
. This gives us maximum portability, and also forces us to code concisely and document vigorously.
I was also reading on php.general tonight, and noticed some questions about PHP standards. Several people contend that PEAR is becoming the de facto standard, as it's the de facto extension library. In addition, because it is becoming a standard, there's also a standard for documenting projects, and this is phpdocumenter. The relevant links are: