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…

Those were:

• AdBlock
• Delicious.com Integration
• The Zend Studio Toolbar

The first two were ported to Safari within days (if not hours) of the Safari 5 release.  The third is likely to take a while, so I decided to put together my own version for the time-being.  Right now it’s very much in an “alpha” stage.  It only supports the “debug current page” command, and it hasn’t been tested all that thoroughly.  That said, I plan on developing this over the next few weeks to mirror most of the features available in the current Zend Studio Toolbar for Firefox and MSIE.

I’m also adding some features of my own.  Namely, the toolbar remembers what domains you’ve enabled debugging on, and only shows itself on those domains.  There’s a browser button that you can use to toggle debugging, and in the future I want to add an indicator when the page you’re on supports debugging.

If you develop with Zend Studio and Safari, please check out the current version of the extension.  I could really use some feedback from other folks (particularly those who have other workflows from me).

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:

Enjoy!

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.

[Update] Here’s a video of both Nick and my talks (sorry, the audio from the wireless mic we were using is pretty quiet):

And here’s the finished code, cleaned up a bit: HTML5 Demo Files [46.58 kB]

It includes the demo page and its supporting files (except the actual video files, which are pretty large).   I took a few moments this morning to clean the file up and add the Mozilla-specific counterparts to the Webkit-specific CSS selectors and functions that I demoed.  I also threw a few extras in there, like transforms, so it’s worth having another look at the code.

One thing I did want to clarify is the @font-face rule.  We had a little trouble getting it to work during the demo, so I spent a few minutes reading up on browser support.  Here’s the breakdown:

• TTF: Firefox 3.5+, Safari 3.1+, Chrome 2+, Opera 10+
• OTF: Firefox 3.5+, Safari 3.1+, Opera 10+
• EOT: Internet Explorer 4+
• SVG: Safari 3.1+, Chrome 0.3+, Opera 9+

It’s worth noting that before Chrome 4.0 @font-face was disabled by default, so even though SVG and TTF were supported by Chrome early on, they weren’t really usable until recently.

When you look at that list it becomes apparent that the best way to get the most @font-face support is to use TTF and OTF formats.  OTF is Microsoft’s “Embedded OpenType” format.  If you have a TTF or OTF formatted font, you can use this tool to convert it to EOT.  Once you have your TTF and EOT files, just copy and modify the @font-face declaration in my demo code.

The last thing I wanted to post is a list of resources.  These are just some tutorials/web sites that either use or talk about HTML5:

• Great presentation on HTML5 written IN HTML5. View in Chrome for best results.
• “How to Make All Browsers Render HTML5 Mark-up Correctly – Even IE6“.  It’s a good overview of how to get browsers to behave, but doesn’t go into much detail beyond that.
• Sample code on how to get <video> to work for everyone (with a fallback for MSIE).
• Sublime video (for consistent UI in <video> tags, with Flash fallback)
• Basic tutorial on using the SQLite-compatible database in your browser.
• An overview of all forms of client-side storage.
• “HTML 5: Features you want desperately but still can’t use“.  Great talk by Ian Hickson from 2008.  It’s a little out of date now, but there are lots of great demos in there.
• Mark Pilgrim’s HTML5 Book “Dive Into HTML5“.
• Modernizr is a JS tool that helps you detect support for HTML5 features.
• Nice chart of HTML5/CSS3 feature support by browser.
• IE7.js and IE8.js, which I mentioned in my talk, help make MSIE perform more like a standards-compliant browser.
• Nissan Leaf product page, made using “HTML5″ (technically it’s still XHTML, but it’s using a lot of JS/SVG/etc to skip the need for Flash in many places).

[Update] Added 4/28:

• CSS3 Solutions for Internet Explorer.  Provides some useful filters and HTC files to make MSIE mimic CSS3 functionality.
• Aves Engine: An HTML5-based social game engine.
• CanvasMol: An HTML5-based web app for molecular modeling.
• A good overview of HTML5 video Libraries, Toolkits and Players
• A nice video covering HTML5 features you can use right now.
• Very cool visualization of HTML5 & CSS3 readiness.
• Gallery of 15 HTML5 templates and frameworks.
• Overview of new HTML5 input types, and why you should be using them right now.  Highly recommended.
• Very cool tool for generating cross-browser border radius code.
• Introduction to CSS3 transitions.

[Update] Added 4/29:

• Table of CSS3 Support in Email Clients

That’s everything I can think of right now.  I’m constantly adding new stuff to my Delicious account and/or posting it to Twitter, so keep an eye on those feeds for updates on this stuff in the future.

If you have any questions, feel free to ask in comments or @inxilpro and I’ll do my best to answer or point you in the right direction.

Wouldn’t it be nice if you’d had something like this:

Well, there are two things you can do.  The first is to vote on ZF-9509 and ZF-9508.  But until the documentation is fixed, you can download my Greasemonkey script that gives you a page TOC right now:

[Download id not defined]

Hope you enjoy!

• Create /path/to/vhosts/projectname/public
• Edit /etc/hosts to add 127.0.0.1 projectname.localhost
• Edit /path/to/httpd-vhosts.conf to add a new <VirtualHost> directive for projectname.localhost
• Repeat for each new project

It’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.

First let’s start with Apache, which was always the un-problematic part of the equation.  There’s a great Apache extension called mod_vhost_alias that was made to do just this.  All you need is one slightly modified <VirtualHost> directive and you’re set:

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    VirtualDocumentRoot "/path/to/vhosts/%1/public"
    ServerName subdomains.localhost
    ServerAlias *.localhost
    LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
    ErrorLog "logs/vhosts-error_log"
    CustomLog "logs/vhosts-access_log" vcommon
</VirtualHost>

And you’re also going to want to set directory permissions on all those directories:

<Directory "/path/to/vhosts/*/public">
    Options Indexes FollowSymLinks
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

You’ll also probably want to turn UseCanonicalName Off.  Now Apache is set up to map anything.localhost to /path/to/vhosts/anything/public.  The problem is, your computer still doesn’t know that it should be handling http://anything.localhost.  That’s where the proxy auto-config file comes into play.

Proxy Auto-Config files, or PAC files, were designed to help your browser determine if and when it should use a proxy.  PAC files are actually just simple JavaScript files with one function that takes URL and Host Name arguments and returns a string telling the browser what to do.  Often this would be used to send certain traffic through a proxy, or proxy certain traffic at certain times of the week (it might be useful as a distraction-blocker as well), but in our case we’re going to use it to forward all .localhost traffic back to our local web server.

Just create a file called localhost.pac and put the following inside it:

function FindProxyForURL(url, host)
{
	if (dnsDomainIs(host, ".localhost")) {
		return "PROXY localhost";
	}
	return "DIRECT";
}

Basically what this file is saying is, if the domain is *.localhost, send it to localhost, otherwise just connect directly.  All you have to do is save that file and tell your browsers to use it, and you’re set.  Each browser is a little different, but most (if not all) support PAC files:

• Safari: System Preferences -> Network -> Advanced… -> Proxies -> Automatic Proxy Configuration
• Firefox: Preferences -> Advanced -> Network -> “Configure how Firefox connects to the Internet” -> Automatic proxy configuration URL
• MSIE: Tools -> Internet Options -> Connections -> LAN Settings -> Use automatic configuration script
• Chrome: Uses Safari/Internet Explorer settings
• Opera: Preferences -> Advanced -> Network -> Use automatic proxy configuration

Now, when you go to http://mynextawesomeidea.localhost your system will automatically attempt to load /path/to/vhosts/mynextawesomeidea/public.  Any time you want to start a new project, just create the directory and go!

A couple notes: this technique messes with a few environmental variables.  Apache seems to get confused about your DOCUMENT_ROOT and REQUEST_URI.  Your document root is going to be your global document root, not the /path/to/vhosts/… directory, and your REQUEST_URI will include the hostname and protocol parts, not just the path and query parts.  Another side effect is that you need to set your RewriteBase to / if you’re using mode_rewrite.

The book is structured in two parts.  The first two chapters cover the basic setup of the Zend Framework (ZF) and, more specifically, a look at its Model-View-Controller (MVC) implementation.  Almost all of the book from there on out focuses on building a real-world ecommerce application using ZF.  I tend to be a learning-by-doing type of person, which I think tends to be true of many programmers, so I think this is a pretty good way to lay out a book.

Much of the book focuses on Models, and how to use various ZF components to implement your domain logic.  Most people agree nowadays that you should have fat models and skinny controllers (in that your controllers should really just have enough code to facilitate your models doing the work), and Keith Pope’s focus on models really hits this home in the book.  The topics of user accounts, the shopping cart and the catalog are all addressed in this light, while still bringing up topics like forms, controllers, views, action helpers, etc.

In general, the book focuses on best practices, which I think is really important for new ZF developers.  Because one of the guiding principals of the Zend Framework is that it gives you freedom to implement things however you like and use only the components you want, it can be hard for people just getting started to get a sense of how they should use certain components, and particularly how everything falls together in a “typical” MVC application.   Following along with the development of the storefront application in this book is a great way to see how those components often are used together.

That said, there are ways in which the code in this book is outdated or less-than-ideal.  As with anything that moves as fast as the Zend Framework has been moving, it’s hard to keep up with the latest tricks and best practices (and in some places it feels like they skipped on editing to try to publish the book before it got too outdated—there are plenty of minor code inconsistencies and typos throughout).  This book is a good place to get started, but keep in mind that the Zend Framework is already at 1.10, with 2.0 on the horizon, so anything that’s not the Zend Framework Official Documentation is in danger of being out of date at any moment.

Also, keep in mind that there’s already a lot of good information out there, so if you don’t mind finding it yourself, you might not need a book.  In fact, I found that most of the code in the authorization chapter was almost a direct copy of Matthew Weier O’Phinney’s blog post on Applying ACL’s to Models.  If you read blogs like Matthew’s (who is the project lead for ZF, and a fantastic resource) and spend time on #zftalk you can figure most things out on your own (Ben Scholzen’s demo application is another good starting point).  The information may be a little scattered, but it’s out there.

In the end, I think that this book would be a really helpful resource to someone who’s just getting started with MVC architecture and other design patterns in PHP.  It also is a good way to see most of the Zend Framework best practices put to use in one place.  On the other hand, if you want the latest information available and are willing to work for it, everything you need is probably online and free.

Some resources that might be helpful to new ZF developers:

• Zend DevZone
• Questions tagged w/ Zend Framework on Stack Overflow
• #zftalk
• Zend Framework in Action Blog
• Matthew Weier O’Phinney’s Blog
• Ryan Mauger’s Blog
• Ben Scholzen’s Blog

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…

Enjoy!

• Authorize access to a model’s method
• Authorize access to a controller action
• Authorize access to an arbitrary “permission”

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.

By default, whenever Galahad_Acl has a role added to it in the format “namespace:resource.subResourse” (etc) it automatically adds the resources up the chain.  For example, if I add “mvc:default.index.index” to a Galahad_Acl object, it would add the following resources to the ACL:

• mvc:
• mvc:default (parent = “mvc:”)
• mvc:default.index (parent = “mvc:default”)
• mvc:default.index.index (parent = “mvc:default.index”)

Galahad_Controller_Plugin_Acl takes this a step further by automatically adding any controller action that’s dispatched to the ACL and then checking against the ACL.  This means that with the following ACL:

$acl = new Galahad_Acl();
$acl->addRole('guest');
$acl->addRole('staff', 'guest');
$acl->addRole('admin', 'staff');
$acl->addResource('mvc:blog.entry.view');
$acl->deny();
$acl->allow('admin', 'mvc:');
$acl->allow('staff', 'mvc:blog');
$acl->allow('guest', 'mvc:blog.entry.view');

The following would be true:

• Role “admin” would be allowed access to any URL (“admin” is allowed access to “mvc:”)
• Role “staff” would be allowed access to /blog/entry/edit even though permissions weren’t explicitly set for the resource “mvc:blog.entry.edit” (because “staff” is allowed to access “mvc:blog”)
• Role “guest” would be allowed to view /blog/entry/view but no other portion of the blog (“guest” is allowed access to the specific resource “mvc:blog.entry.view”)

Galahad_Model_Entity works similarly.  By default each entity adds itself to the ACL in the format “model:module.modelName” so that the model Default_Model_User has the resource ID “model:default.user”.  Each model has a method called _initAcl which lets you manage permissions on a per-model basis.  This is better demonstrated in code:

class Default_Model_Post extends Galahad_Model_Entity
{
    protected function _initAcl($acl)
    {
        // Deny permissions to anything on this model unless explicitly allowed
        // We don't have to add "model:default.post" because Galahad_Model_Entity
        // automatically does that for us
        $acl->deny(null, $this);
        // Allow guests to fetch the content of posts
        $acl->allow('guest', $this, 'fetch')
        // Allow admins to save changes to posts
        $acl->allow('admin', $this, 'save')
    }
    public function save()
    {
        if (!$this->getAcl()->isAllowed($this->getRole(), $this, 'save')) {
            throw new Galahad_Acl_Exception('Current user is not allowed to save posts');
        }
        $dataMapper = $this->getDataMapper();
        return $dataMapper->save($this);
    }
}

So, as you can see, the model denies access to itself unless explicitly allowed, and then allows access to certain methods for certain roles.

All three of these classes are in their early stages of development, but I’d love some feedback on the ideas/suggestions on how to make them better.

Check out the code on GitHub:

• Galahad_Acl
• Galahad_Controller_Plugin_Acl
• Galahad_Model_Entity

Also, for more information about the Galahad_Model system, check out my previous post on modeling in the Zend Framework.

Recently I was building a form that contained a URL field, and after browsing the Zend_Validate docs, I was surprised not to find a Zend_Validate_Uri component.  Luckily, Zend_Uri already validates URIs, so it was just a matter of writing a wrapper that followed the Zend_Validate APIs.  Basic usage:

$validator = new Galahad_Validate_Uri();
$validator->isValid('http://www.google.com/');

Obviously this would be much more useful when combined with Zend_Form or some more extensive validation chains, but you get the point.

Grab Galahad_Validate_Uri from GitHub.

The second issue I often deal with is people forgetting (or not knowing) to include http:// in the URLs that they submit.  Rather than solve this at the controller-level, I decided this was a common enough problem to build a Zend_Filter component for.  Basic usage:

$filter = new Galahad_Filter_PrependHttp(array(
    'allowedSchemes' => array('http://', 'https://', 'mailto:'),
    'checkUri' => true,
));
echo $filter->filter('google.com'); // Prints 'http://google.com'

This filter takes any string and prepends “http://” to it if it doesn’t already contain an allowed scheme (more on that below).  By default it allows “http://”, “https://” and “mailto:” schemes, but you could set this to anything (say you want to allow “itms://” [iTunes] links) by setting the ‘allowedSchemes’ option.  It also (optionally) checks if the resulting URI is valid, and only applies the filter if it is (effectively only prepending “http://” to otherwise valid URIs).  Remember, though, that “http://something” is technically a valid URI, so that will be accepted.  In the future I hope to add additional options to limit to URLs that follow certain standards.

Grab Galahad_Filter_PrependHttp from GitHub.

Update: I’ve submitted Zend_Filter_PrependHttp to the Zend Framework wiki for comments.  Check it out and let me know if you think there’s anything I should change (I’ve posted a few ideas already).

The validator and filter work well together with Zend_Form to create URL form elements:

$this->addElement('text', 'my_url', array(
    'label' => 'URL:',
    'filters' => array('StringTrim', 'StringToLower', new Galahad_Filter_PrependHttp()),
    'validators' => array(new Galahad_Validate_Uri()),
));

The form element generated by that code will produce fairly normalized, valid URIs.