What’s Smarty?
Six months later… and I don’t miss Smarty at all. I’m perfectly happy with Zend Framework’s view scripts and PHP’s alternate syntax tags. Accepting view scripts was easy enough, it’s part of the framework so I might as well use it. However I still couldn’t accept seeing PHP code in my HTML templates:
<table>
<?php foreach($tableData as $dataRow) { ?>
<tr>
<?php foreach($dataRow as $data) { ?>
<td><?php echo $data; ?></td>
<?php } ?>
</tr>
<?php } ?>
</table>
When I discovered PHP’s alternate syntax, it just made sense. Especially if one keeps the alternate syntax in the view script only. And I think the syntax itself is much easier for The Designer (who doesn’t know/care about anything that is PHP) to understand:
<table>
<? foreach($tableData as $dataRow): ?>
<tr>
<? foreach($dataRow as $data): ?>
<td><?= $data ?></td>
<? endforeach; ?>
</tr>
<? endforeach; ?>
</table>
And at the same time I don’t get asked those endless ‘what the hell does {section} mean?’ questions anymore.
I Miss Smarty
The last couple of days I’ve been getting my hands dirty with the codebase of one of the projects at work. At first I was kind of excited because it’s always a good experience becoming familiar with the unfamiliar. But imagine how my heart sank when I opened that first .php file and saw code like the following:
<table>
<?php foreach($tableData as $dataRow) { ?>
<tr>
<?php foreach($dataRow as $data) { ?>
<td><?php echo $data; ?></td>
<?php } ?>
</tr>
<?php } ?>
</table>
Yes that’s right. PHP code mixed with the HTML markup. It’s a far cry from the neatly formatted Smarty templates that I’ve been working with the past 2-3 months.
There are three places where I usually see this kind of ‘unfortunate’ code:
- PHP for dummies books
- Templating systems
- Ajax payloads from the server
A free cookie to the first reader to guess correctly which category The Project falls in.
Although there’s a good reason why much the codebase is written like the above, that justification doesn’t make working with it any easier. Case in point: I spent the better part of this afternoon pulling my hair out trying to figure out why a block of HTML wasn’t showing up and it was all because I misplaced a </div> insde a triple nested <foreach> structure.
Not the best way to spend your afternoon. Especially during the first week of a new job…
Music Database
How awesome is JQuery’s Ajax and XML parsing functions? It helped me implement the basics for my ajaxish music database application all during my lunch break today at work. I’ve been putting off creating it mainly because I didn’t want to deal with writing the tedious Ajax and XML parsing code that’s necessary for Ajax stuff.
And when I say ‘basics’ I mean everything except for the interface (ie. the HTML / CSS part). I was trying to go for the Homebrew style of OS X’s Terminal application but since I’m not much of a designer it was difficult getting that exact look. Also note that ‘basics’ really means ‘not production ready’ but since this is just a personal project kind of thing what do I care how polished things are.
How Truth Tables Ruined My Afternoon
This piece of code was killing me this afternoon:
$DB_ERROR = -1; $API_ERROR = -2; $UI_ERROR = -3; $errorCodes = array($DB_ERROR, $API_ERROR, $UI_ERROR); $returnCode = TRUE; $isError = in_array($returnCode, $errorCodes); print($isError);
I was expecting $isError to be FALSE but it kept turning up as TRUE. I just couldn’t understand it. That is until I read the online docs:
When converting to boolean, the following values are considered FALSE:
* the boolean FALSE itself
* the integer 0 (zero)
* the float 0.0 (zero)
* the empty string, and the string “0″
* an array with zero elements
* an object with zero member variables (PHP 4 only)
* the special type NULL (including unset variables)
* SimpleXML objects created from empty tagsEvery other value is considered TRUE (including any resource).
Do you see what I was assuming here? I considered TRUE to be a 1 and FALSE to be everything but a 1. I guess I’m just so used to those truth tables with 1 representing true (thank you very much Discrete Mathematics For Computer Science). But hey you’ve gotta work with whatever the language gives you.
At first I thought about converting $returnCode to an integer before I make that in_array comparison but then after reading more of the online docs I found something cleaner:
$isError = in_array($returnCode, $errorCodes, TRUE);
That extra TRUE checks the types as well as the values.
The Double Submitting Form
From the ‘Thank God We Have External Users As Testers’ department comes the following bug: The Project has this one particular form which takes forever (thank you third party API) to complete. Because of the whole ‘Did I Click On That Submit Button Or What?’ feeling that a user may experience when interacting with this particular form, he/she may be compelled to hit that submit button again. Which produces less than desirable results.
The (client side) fix that I found was rather straightforward. Just disable the submit button when the form is submitted:
$('form').submit(function()
{
$(this).find('input:submit').attr('disabled', true);
});
However… a small problem. When the form is submitted with the disabled submit button, the value of that submit button isn’t included in the POST values. Which kind of sucks because The Project uses the value of the submit button to check if the form should be processed or not:
$processForm = isset($_POST['SubmitButton']);
if ($processForm)
{
// process your form
}
else
{
// show an error page or something. NOT supposed to be here
}
I had to figure out another way to check if the form was actually POST‘ed or not. I decided to check whether a POST array exists:
$processForm = isset($_POST) && count($_POST) > 0;
Not as clean… but it works.
As for the server side solution… I needed to track (with a $_SESSION variable) when the form is first submitted and whether or not it’s been completed. That way if the form is double submitted that second submit can be handled:
$processForm = $_SESSION['IsFormBeingProcessed'];
if ($processForm)
{
$_SESSION['IsFormBeingProcessed'] = TRUE;
// when the form processing is finished set the tracking to false
$_SESSION['IsFormBeingProcessed'] = FALSE;
}
else
{
// forward to a 'Stop hitting that submit button!' page
}
Not even close to being clean… but it works.