I’ve had a couple of small tasks where I’ve needed to toggle the onclick events on a page element. It was surprising how difficult it is to get a straight answer on how to do this.
function hide_field() {
my_element.onclick = function() { show_field(); };
}
function show_field() {
my_element.onclick = function() { hide_field(); };
}
Working with form check boxes can be a bit of a pain on sites with dynamic content. Saving the checked data is easy, but how do you easily save the unchecked value without manually adding it to an array from inside your code? Keep reading.
revealCMS is working great – I’m really starting to see a lot of its strengths (and, admittedly, some weaknesses) as I use it more and begin extending it. Due to how data is saved to the database, the HTML checkboxes were a bit of a problem when trying to save their unchecked state. Typically I save the post data to the object, where it is filtered and scrubbed, as necessary.Only the posted values get updated in their respective rows (makes sense, right?).
The problem is that unless a box is checked, it’s not going to be sent with the form – a problem if you have a checked box, but want to save the unchecked state.The first option is easy and probably the first solution you’d think of – write a couple lines of code for every single checkbox and set it to some default value if it’s left unchecked when the form is posted. Fine, but that takes more thinking than I want to do for something so simple, and it’s somewhat prone to error. Instead…
…the solution: Insert a hidden form field with the same name as the checkbox and the default value right before the place where the checkbox is located:
<input type="hidden" name="box1" value="0" /> <input type="checkbox" name="box1" value="1" />What happens here is that when the checkbox is left unchecked, the hidden field’s value gets submitted, as-is. When the check box is checked, the hidden field’s POST value gets overwritten by the activated checkbox’s.
Unactivated: Hidden field’s value.
Activated: Check box’s value.
Told you it was easy!
I’m looking into new JS frameworks for frontend enhancements, and came across MooTools on recommendation from a friend. The framework has lots of cool features and seems pretty simple, but one thing I’m most impressed with is the download page. It acts just like the *nix package managers – allowing to you pick and choose which modules you’d like to download – even auto-selecting dependencies. Definitely a novel idea for the web.
The Flood website redesign has finally launched. On the back-end is the upcoming revealCMS. There are still a few bugs here and there that I want to iron-out before I make it a 1.0 release, but it’s getting there. Overall it’s been a very stable release. The only hiccups we’ve really had to date are with little server quirks and file permissions, but other than that pretty solid.
Some of my most immediate fixes are mostly in the user experience realm. Just from really using it over the last month or so, I’ve found a few areas that can be improved, or shortcuts added.
Next step: revealCMS.com upgrade.
I just received word that one of my projects just won a Davey Award for online marketing and email campaigns:
Munchkin’s Project Pink: Email a Duck, Raise a Buck!
Harley Bergsma at the UXB and I devised this brainchild together. From there he took care of project management and I took care of developing the back-end. The idea is that users can decorate their own pink duck on the site (using Flash), then forward their creation to all their friends. For each person that receives the duck and opens (don’t even have to click links!) the email five cents is donated to Susan G Komen for the Cure. One of the coolest things is that the email dynamically shows how much the duck raised (how many emails were sent) and how much the project’s running total was. If you were to come back to the email a few minutes, days, weeks later, it would continue to show fully-updated information. Rad!
In just a couple months there were over 131,000 forwards, for a total of over $6550 raised just from this part of the campaign alone.
The problem recently presented itself to me when writing some new functionality for revealCMS: I needed to set some variables to load in the page head, but could only be set after a portion of the body had completed rendering. I wrote a plugin that essentially loads a different stylesheet depending on the input of the Smarty template function. The hard part wasn’t assigning the variable – it was figuring out the best way to get that assigned data to appear in a part of a page that had already been rendered – the head.
It makes sense why Smarty would work this way – that you can’t go back and re-assign variables. It would be too messy. So somehow you need to assign the variable first in the body, then go back and render the head. It’s simple… really. Believe it.
But why bother? Why not put <style> tags directly into the page body where the plugin is located? The reason is simple: <style> tags (and <script> tags, for that matter) MUST be in the page header. It’s a web standards thing.
First, break-up your page templates into two sections: the header (containing everything before the <body> section of your template), and the body, which contains the <body> section. First render the body using
$body = $smarty->fetch('body.tpl');
At this point, I’ll just assume that your page functions have loaded and you’ve either placed an {assign} tag somewhere in the template, or you’ve used a $smarty->assign() inside the template function. If you’re not familiar with $smarty->fetch(), it’s just like $smarty->display(), except it outputs the contents to a variable rather than the screen. And just like display() it can also take $compile_id and $cache_id as optional parameters.
Now render the head:
$head = $smarty->fetch('header.tpl');
By this point everything should work-out as we expect it. Our dynamically loaded css file is loaded in the head and our standards friends are happy. The beauty about this example is that you can now render a number of items in any order you need them then display properly, so long as it makes logical sense.
Here’s a tip: You can use this method to dynamically load javascript files and frameworks if your fancy web 2.0 page functions/plugins need it at some times, but not at others.
I recently read an article over at A List Apart, called Frameworks for Designers. It got me thinking. Actually no it didn’t. The idea was so brilliantly obvious! And sometimes we even do it (such as using blank CSS templates), but not quite like how Jeff Croft describes the process.
From a developer’s point of view it makes a lot of sense. We make all sorts of little include files that do things and we include them into our scripts when we need that sort of funtionality. Jeff explains how designers can do similar types of abstraction with CSS and other elements, which really is one of those “Duh!” type moments. Honestly. One file for tabbed browsing, another for forms styling or page layout. At the same time you can include various javascript for functionality of effects.
At 212Interactive we have a few elements like this, though definitely not quite as sophisticated as the article suggest could/should be done.
My other contract jobs are a mish-mash of projects that haven’t quite made it far enough to use this technique, though I am planning on using something similar for the upcoming RevealCMS (alpha and beta coming this summer).
Here are some free XHTML/CSS templates to get you started with your own framework for design. twe.nty3.com
I’ve been thinking about the things PHP needs to remain relevant. I don’t mean to say that it is becoming irrelevant, but as many people are becoming wooed by Ruby on Rails, the way PHP is done is becoming more and more … tiresome.
We like Rails because, well, it’s just cool. PHP as a language isn’t all that great, just as Ruby as a language is yet another scripting language, however the framework makes all the difference. As I mentioned, Rails is great because it take care of a lot of tedium and makes programming actually kinda fun. PHP has several frameworks available, but nothing is standard. And that’s a problem. These projects, even the popular ones, remain on the fringe of PHP development; each framework is competing with the others for users and developers. We’re playing a game of divide and conquer on ourselves. The winner might be Ruby on Rails, or whatever the next new language/framework will be.
Continue reading “What PHP Needs!”
Let’s say you have a problem: A recent DB migration has escaped a lot of quote marks within your fields and now your app is acting funny. Your task is to fix the problem, and do it FAST.
Enter the replace() function in MySQL (assumed other RDBMs as well, such as Postgres and MSSQL)
UPDATE table_name SET table_field = replace(table_field, replace_that, with_this);
I was seeing a lot of ” text in some forums output, so I was on a mission to make nice with the forums administrator:
update posts_text set post_text = replace(post_text,'\"', '"');
Double backslash? Yes. Quotes are OK, but the backslash is an escape character, so to actually print the backslash, you need to escape the escape character. You’d do the same if you wanted n to not be treated as a newline return: \n
Here’s a fun little thing you can do for your next site goodie: display your users’ “fortunes” from the command-line interface, CLI, application Fortune.
On Fedora, install:
% sudo yum install fortune-mod
from PHP (fortune.php)
<pre>
<? passthru('fortune'); ?>
</pre>
I pre-formatted the text because it comes out looking as it does in the CLI. In its simplest form you can simply include this into a nice little div tag somewhere on your site (little side box above/below the nav?). If you don’t have privileges to install apps on your machine, this probably won’t work for you.
While you’re at it, take a look at simply parsing RSS feeds for your site. I found a good source over at BrainyQuote.com. Give it a shot!