Articles in "PHP5"
Data Security in a Digital Age
Bruce Schneier has a wonderful essay up at wired.com today about data security. From the article:
Whoever controls our data can decide whether we can get a bank loan, on an airplane or into a country. Or what sort of discount we get from a merchant, or even how we're treated by customer support.... If a criminal can get hold of enough of our data, he can open credit cards in our names, siphon money out of our investment accounts, even sell our property. Identity theft is the ultimate proof that control of our data means control of our life.
We need to take back our data.
The protection of personal data is something I'm faced with freqently and something I take very seriously. In many cases, it seem to me like people collect too much private information. Why, for example, would you need to enter your birthday to signup for a newsletter. And, even if there is an age requirement for the newsletter, you could always lie about your birthday and, thus, circumvent such "security" measures.
Mr. Schneier goes on to say that it will take years to get to a point where we can truly "take back our data." I agree it will take time, but I think it's up to us -- the web developers of the world -- to truly analyze the data that we collect and make sure that we take the appropraite steps to secure it. Only in that way will we move toward a world where our data is within our control.
Using Prototype to Load Javascript Files
The calendar on this site only appears on pages that show blog-related information. That calendar is enhanced with Javascript allowing you to change the month displayed by the calendar without reloading the rest of the page. So, in order to ensure that these enhancements would be available everywhere the calendar is, I figured I had two options:
- Code the inclusion of the Javascript file into every page which requires it. While a good solution, and one that has worked well in the past, sometimes it can be difficult to remember or realize that you've forgotten to include the file when you add new pages that require it.
- Find a way to automatically include the file when it's needed. This would avoid the need to remember the need to include it when adding new pages that require it, but would result in a little more Javascript going on when the page loads.
This past weekend, with a little help from the Prototype Framework, I found a solution for #2 above which I am, for the moment, quite pleased with. The following snippet assumes the most recent version of Prototype as of this writing (1.6.0.2):
document.observe("dom:loaded", function() {
var calendar = $("calendar");
if(calendar) {
var script = new Element("script", { type: "text/javascript", src: "/path/to/calendar.js" });
document.observe("calendar:loaded", function() { new Calendar(calendar); });
$$("head")[0].insert(script);
}
});
Here's, essentially, what it does:
- Uses the custom dom:loaded event which, since Prototype 1.6.0, determines when the DOM is ready for manipulation to call the anonymous function defined in the snippet.
- That function attempts to get a reference to the calendar. If it can't, then nothing else happens. This makes sure that we don't include the calendar Javascript unless we need to.
- Once we've found a calendar:
- Create a new javascript element pointing its src attribute at the source for the calendar's code.
- Tell the document to observe the calendar:loaded event, which is fired from the bottom of teh calendar's javascript.
- Insert the javascript file into the head of the document.
It's #3.2 that is the most important step. The calendar.js file makes sure to use the Prototype fire() method to create the custom calendar:loaded event. Thus, when the browser is done performing the necessary work required to insert the calendar.js file, it'll fire the custom event, which will be caught by the document object to instantiate the newly inserted Calendar.
In other words, with a creative use of Prototype's Event.observe() and Element.fire() methods, we not only include Javascript files only when they're needed, but also ensure that we don't attempt to use the code within those files until the browser is ready for it to be used.
PHP for the win!
Well, I Missed the Memo
Some days you learn about something so amazingly life altering you know nothing will ever be the same. Most of the time, the average person doesn't encounter such things within a programming language. Today I learned of a fourth argument to the PHP htmlentities() function that ensures that html entities won't get double encoded. So, what does this mean to you? Probably nothing, but if you're running PHP 5.2.3 or greater, you can also benefit from this most joyous of days.
