My Zend Problem Solved—with MegaFunk!
As of the 10th imperial month in the royal year 2008, my Zend Framework development has stagnated, leaving SonghaySystem.com (built on Zend 1.0.3) little to celebrate. In the 2008 article, “Regression in the Zend Framework Aimed Right at My Peeve,” I was complaining about how my XML configuration files would break on newer versions of the Framework. But the reason why I thought this was happening was wrong—I even dragged helpful Zend people like Matthew Weier O’Phinney into this!
When the time came to continue with the development of MegaFunk.com, the opportunity to experiment with the latest Zend build made sense to me. This site is now live with an XML configuration file showing none of the problems I’m having with SonghaySystem.com! So what’s the difference? The clue is in the Zend Framework Programmer’s Guide, “10.13. Migrating from Previous Versions”:
When writing URLs, the documented way to write camelCased action names is to use a word separator; these are ‘.’ or ‘-’ by default, but may be configured in the dispatcher. The dispatcher internally lowercases the action name, and uses these word separators to re-assemble the action method using camelCasing. However, because PHP functions are not case sensitive, you could still write URLs using camelCasing, and the dispatcher would resolve these to the same location. For example, ‘camel-cased’ would become ‘camelCasedAction’ by the dispatcher, whereas ‘camelCased’ would become ‘camelcasedAction’; however, due to the case insensitivity of PHP, both will execute the same method.
This causes issues with the
ViewRendererwhen resolving view scripts. The canonical, documented way is that all word separators are converted to dashes, and the words lowercased. This creates a semantic tie between the actions and view scripts, and the normalization ensures that the scripts can be found. However, if the action ‘camelCased’ is called and actually resolves, the word separator is no longer present, and theViewRendererattempts to resolve to a different location—‘camelcased.phtml’ instead of ‘camel-cased.phtml’.
What the above implies is that in the newer versions of the Zend framework an Action named myCommand (in, say, the XML configuration file) will cause the Framework to look for mycommand—and, in my sad case, for over four months, throw an exception on my dev’ (virtual) machine about not finding mycommand. Since PHP is case insensitive (mostly), it never occurred to me (for over four months) that the Zend Framework would even be in this context. The solution to this nagging problem is entering my-command in the configuration file (or my.command). More details I have written in my Funky Knowledgebase article, “Zend Framework PROBLEM: Configured Routes with Camel-Casing Throw ‘Action Not Found’ Exceptions.”
Can I have my life back now? Can I get down one time?