Update: It turns out Safari is more problematic than Firefox, so I’ve switched back. I have no plans to finish this project. Feel free to fork it on GitHub.
When Safari 5 came out I decided to make the switch. The new Safari developer tools rival Firebug, Safari now supports extensions, and Firefox has been causing all sorts of problems for me lately (20-second freezes, choppy video, etc). There were three things that I knew I couldn’t live without…
Just saw this (via Daring Fireball):
Cross-browser kerning-pairs & ligatures
And thought, “there’s gotta be an extension for that.” Well, looks like there isn’t… so I made one:
Optimize Legibility [4.64 kB]Enjoy!
By default, Safari extension toolbars are just plain old HTML. That means that your toolbar is going to look a lot like:
Wouldn’t it be nice if instead it looked like:
I’ve developed a (very) simple CSS file that styles links (and <button> elements) to look like native Safari toolbar items. Download it now.
On April 27th I spoke at PANMA’s HTML5 Demystified event, demoing some of the new features that HTML 5, CSS 3 and other modern web standards bring to the table. There was a great turnout—I’m glad we hit on a topic that so many people are interested in. This post is just a quick follow up and a place for people to download the code I put together during the event and to check out some resources on HTML 5.
If you’ve every tried to navigate the Zend Framework documentation’s longer pages you’ve probably looked everywhere for a table of contents. Sure, there’s a TOC for the major sections of the component, but if you’re looking for a specific part of a page (or an overview of what that page covers) you’re out of luck. For example, take a look at the Zend_Validate list of standard validation classes. Now try to find the documentation on the URI validator. Can’t find it? That’s ’cause it doesn’t exist. Too bad you had to scroll down through 39 page-lengths’ worth of documentation to find that out.
I often tell my co-workers that if they’re doing the same basic thing over and over again, to let me know, because there’s probably a way to automate it. That’s why whenever I used to start a new web development project I’d feel a twinge of guilt. Does this look familiar?
127.0.0.1 projectname.localhost<VirtualHost> directive for projectname.localhostIt’s not a big deal—maybe a two minute distraction—but it always bugged me. I’d looked into automating this before, but it always led to me installing a DNS server on my local machine, which is something I don’t particularly want to do. Then, just a few days ago, I accidentally stumbled on to a fantastic cross-platform solution.
Continue reading “Automatic Virtual Hosts w/ Proxy Auto-Config” »
At the beginning of February PACKT Publishing sent me a copy of Zend Framework 1.8 Web Application Development by Keith Pope and asked me to post a review. Unfortunately a bunch of stuff came up, so it wasn’t until this last week that I got a chance to really look it over. Here are some of my thoughts.
Continue reading “Review: Zend Framework 1.8 Web Application Development” »
If you use the Zend Framework CLI interface much you probably find yourself expecting tab-completion to work. Well, with this bash completion script it will. Just add the following line to your .bashrc or .bash_profile:
source path/to/zf.bash
Next time you load the terminal, you can type “zf c” and hit TAB twice to see a list of available commands (change, configure and create” or type “zf cr” and hit TAB to have “create” automatically inserted for you. The script works for both action names and provider names (but not for anything past that). Eventually I want the script to dynamically load the available commands (so that it works with custom providers and future versions of ZF without updates) but I couldn’t get that working for this version so I just hard coded them.
There’s also a version that completes commands from the Galahad Framework Extension if you’re testing that out…
Zend Framework CLI Bash Completion Script [1.71 kB]Enjoy!
In most of my applications I like to handle authorization (querying the ACL) in one (or more) of three ways:
In general I find it’s best to keep authorization within the domain (querying the ACL within my models when they’re accessed) as this provides the most consistent behavior. For example, if I eventually add a REST API to my application I don’t have to duplicate all my authorization logic in the new REST controllers. When the application calls something like Default_Model_Post::save() it either saves or throws an ACL exception, no matter where it was called from. This is great in that it saves me from having to duplicate code and keeps my system more secure.
On the other hand, there are times when it’s just a lot easier to handle authorization in the controller. For example, if guests should never access my “Admin” module, it doesn’t make sense to ever let them access /admin/ URLs. Also, if you’re using Zend_Navigation, having ACL resources that match controller actions lets you utilize its ACL integration.
If you’re ever going to mix these two techniques, you’ll eventually bump into the case where a model and a controller share the same name. What if you need to set permissions on a “user” controller and different permissions on a “user” model? This is where namespacing comes into play. As suggested by the Zend Framework manual, I always name my controller action resources in the format mvc:module.controller.action. I name my model resources similarly, in the format model:module.modelName.methodName. In both theses cases, “mvc” and “model” are the namespace, and everything following the colon is the actual resource name. Now I can refer to my “admin” module as mvc:admin and the models within my admin module as model:admin.
This is where things get interesting. If you set up your ACL chains correctly, you can set permissions on whole modules or models and have those rules cascade to their child controllers or methods. For example, say you set up your ACL as follows:
$acl = new Zend_Acl();
$acl->addResource('mvc:');
$acl->addResource('mvc:admin', 'mvc:');
$acl->addResource('mvc:admin.user', 'mvc:admin');
$acl->addResource('mvc:admin.user.create', 'mvc:admin.user');
$acl->addRole('guest');
$acl->addRole('admin', 'guest');
$acl->deny();
$acl->allow('admin', 'mvc:admin');
Now if a user with the role “admin” tries to access the resource “mvc:admin.user.create” (http://basename/admin/user/create) they will be allowed, but a user with the role “guest” will not. Using this technique gives you as much granularity as you need in your ACL, but at the same time lets you set broad permissions where appropriate.
This is where Galahad_Acl comes into play. Setting up all these resources can be tedious, as is checking permissions in each controller. Galahad_Acl in conjunction with Galahad_Model_Entity and Galahad_Controller_Plugin_Acl automate everything but the actual permissions that are specific to your application.
Continue reading “Namespacing ACL resources & Galahad_Acl” »
For the last couple of months I’ve been incorporating portions of applications I’m working on into my Galahad Framework Extension project. Right now it’s not at a point where I’d feel comfortable promoting it (you can check out the project on GitHub if you want), but there are portions that are pretty solid that might be useful to others right now. Two such portions are Galahad_Validate_Uri and Galahad_Filter_PrependHttp which are both very useful for processing forms with URL fields.