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.
[Updated with follow-up video]
About a month ago I posted some ideas about PHP modeling in the Zend Framework and requested feedback. After a month of on-and-off discussions through this website and #zftalk I decided to sit down and implement things a little more.
Continue reading “More PHP Modeling (w/ video demo)” »
I’ve been toying with the idea of using my cache as a data store for a project where the data doesn’t need to be updated very often. Basically, I’d write out plain XHTML documents and then parse the data using XPath when needed. But that’s a different story. Once I decided to give my idea a try, I started thinking about how to store authentication information. The application doesn’t store any private information, so authentication is only needed to prove that you are authorized to edit the information. So why not store the authentication information publicly as well (as an HTML comment at the top of the file)? Here’s what I was thinking, in pseudo code:
identity = base64(encrypt_rijndael256([ sha512_hmac(username, appUsernameSecret), sha512_hmac(password, appPasswordSecret) ], appSecret))
This would produce an base64 representation of an encrypted array of hashes. Basically, the system would produce two hashes using HMAC and two separate secret keys (one for the username hash and one for the password hash). It would store that data in a way that it could later retrieve it (in my case a serialized array) and then encrypt the whole thing with a third key (the base64 is just so it could easily be represented by an ASCII string). That way there are multiple points of failure. An attacker would have to know all three keys just to get at the hashes, but then that’s all they’d have. They’d still need to brute force both the username and password separately. It seems to me that this would be pretty darn secure. Clearly not good enough for a bank, but certainly fine for a web app that would have very few negative consequences if it were broken into.
I would love feedback from someone who know’s what they’re talking about
Below is some working PHP code to illustrate my point:
This just came up on #zftalk, and it appears that the information out there is either incomplete or incorrect, so I thought I’d just put out a simple solution. Here’s a simple way to calculate the difference between two Zend_Date objects (in days):
$jan1 = new Zend_Date('1.12.2009', Zend_Date::DATES);
echo "\nJanuary first: ", $jan1->toString();
$christmas = new Zend_Date('25.12.2009', Zend_Date::DATES);
echo "\nChristmas is on: ", $christmas->toString();
$diff = $christmas->sub($jan1);
echo "\nNumber of days: ", $diff / 60 / 60 / 24;
I’ve been thinking a lot about Modeling in a MVC application, particularly in the Zend Framework. Obviously each application is different, and any Model is going to be fairly unique to your application. That’s why ZF doesn’t provide a base Model class. That said, there are some design patterns that a lot of people are using nowadays, and applications could use some base functionality to facilitate those patterns.
Zend Framework’s project lead, Matthew Weier O’Phinney, has a lot of great thoughts about Modeling that I’ve been trying to stick to. In implementing those ideas, I’ve started thinking out some base classes to build my Models on top of. Obviously these classes won’t work for everyone. But they should work for a lot of “typical” web applications.
Recently a bunch of people have been proposing ways to produce short URLs without relying on 3rd parties (tr.im nearly shutting down definitely hit home the need for this discussion). One option was the rev=”canonical” attribute. Others have been various rel values. I like what PHP.net has done—just combine them all and see which one wins out:
<link rev="canonical" rel="self alternate shorter shorturl shortlink" href="..." />
I haven’t yet implemented my own short URLs, but when I do I think that the way I’ll go.
I’ve been thinking a lot lately about how to most effectively use video as an online sales tool, and it seems to me that auto starting a video can be a power conversion tool. The problem is, it also can be really (really!) annoying to some (or many) of your users. Like most things, I think that your target audience should guide your decision about autoplay, but if you do decide to use it (or at least to test it) how can you avoid some of the pitfalls? I have a few ideas that I’ve been playing with and I shot a real quick video to demo them. Let me know what you think, and also if you see any other potential problems/solutions.
Someone was recently asking on ZFTalk about how to use a different layout for each module in your application. Since this is a problem I’ve dealt with in the past and planned on adding to the Galahad FE, I thought I’d quickly write up a tutorial on how to do it:
Put the following class in a library/Galahad/Controller/Plugin/Modularlayout.php file (you’ll probably have to create all those directories and the file).
<?php
/**
* This file is part of the Galahad Framework Extension.
*
* The Galahad Framework Extension is free software: you can redistribute
* it and/or modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation, either version 3 of the
* License, or (at your option) any later version.
*
* The Galahad Framework Extension is distributed in the hope that it will
* be useful, but WITHOUT ANY WARRANTY; without even the implied warranty
* of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* @category Galahad
* @package Galahad
* @copyright Copyright (c) 2009 Chris Morrell <http://cmorrell.com>
* @license GPL <http://www.gnu.org/licenses/>
* @version 0.2
*/
/**
* Use separate layout per module
*
* @category Galahad
* @package Galahad
* @copyright Copyright (c) 2009 Chris Morrell <http://cmorrell.com>
* @license GPL <http://www.gnu.org/licenses/>
*/
class Galahad_Controller_Plugin_Modularlayout extends Zend_Controller_Plugin_Abstract
{
public function routeShutdown(Zend_Controller_Request_Abstract $request)
{
Zend_Layout::getMvcInstance()->setLayout($request->getModuleName());
}
}
Update your Bootstrap.php file’s autoloader initialization method (if you don’t have one, add one):
protected function _initAutoloaders()
{
$this->getApplication()->setAutoloaderNamespaces(array('Galahad_'));
return $this;
}
Please note: You might need to have other namespaces in there, like My_ or App_ or Default_.
Update your Bootstrap.php file’s plugin initialization method (if you don’t have one, add one):
protected function _initPlugins()
{
$this->bootstrap('autoloaders');
$this->bootstrap('frontController');
$plugin = new Galahad_Controller_Plugin_Modularlayout();
$this->frontController->registerPlugin($plugin);
}
Just make sure you have a layout file in your layouts directory for each module (modulename.phtml).
For some reason this took me a long time to figure out, so I thought I’d post it in case other people are having similar problems. I wanted www.mysite.com to route to the www module and app.mysite.com to route to the app module. In the end it was quite simple—I was trying to make it much more complicated than it needed to.
I’m using Zend Framework 1.8.4 with Zend_Application
Here’s my router configuration:
resources.router.routes.www.type = "Zend_Controller_Router_Route_Hostname" resources.router.routes.www.route = ":module.mysite.com" resources.router.routes.www.defaults.module = "www" resources.router.routes.www.chains.index.type = "Zend_Controller_Router_Route" resources.router.routes.www.chains.index.route = ":controller/:action/*" resources.router.routes.www.chains.index.defaults.controller = "index" resources.router.routes.www.chains.index.defaults.action = "index"
And here’s my .htaccess rule that redirect to www if another subdomain is used (or no subdomain is given):
RewriteCond %{HTTP_HOST} !^(www|app)\.mysite\.(com|local)
RewriteRule ^(.*)$ http://www.mysite.%2/$1 [R=302,QSA,L]Otherwise it’s just your standard modular structure generated with the zf tool.
This list is clearly not comprehensive, but these are a few things I’ve been wishing for lately or thought of just now.
<li><a href="#">Something</a></li> <li><a href="#">Something Else</a></li>
Wouldn’t it be really cool if on the third list item an auto-complete drop down popped up offering:
<li><a href="#">|</a></li>
Or something similar
- Lorem ipsum (1 paragraph)
- Lorem ipsum (2+ paragraphs…) — would pop up a generator dialog
- Lorem ipsum (list of 10 elements)
- Lorem ipsum (list of elements…) — would pop up a generator dialog
Even cooler would be if it adjusted the suggestions from context—so if you were in a list it would offer a list first, etc.
Recent Comments