A good rule of thumb you'll hear repeated time and again goes like this. "Light controller, heavy models." In my opinion that can be shortened to "Light controllers." Whether your code is heavy in a library, or in a model it doesn't really matter just so long as you can trim your controllers to concise predictable patterns. This allows you to use cool things like action delegates.
After creating a photo gallery for the gazillionth time in multiple php frameworks, and having to customize it each time a different way, etc. etc. you start to wonder, what can I abstract out of this logic to make it easier to build the next time.
Because an action delegate has to share a common pattern between multiple controllers, if one controller has some custom cluter, then it has to forgo the action delegate in favor of it's custom solution. Unfortunately my first approach to thumbnailing uploaded images went something like this.
The bit we are concerned with is...
There are a couple solutions I've experimented with to remove that bit of code from the controller. You could off load it to a preCreate or preUpdate hook in the model, or you could create a postDispatch plugin (a bad solution, please don't do this), or you could not create the thumbnail when you create or update a record. If you don't actually create the thumbnail in the controller then you can normalize your controller to use an action delegate again.
The critics might ask, "How is not creating a thumbnail a solution?" Well if you are using Zend Framework then there's a good chance you've seen this bit of magic.
Though it might not be instantly apparent, this allows something magical to happen. Given a URI http://www.example.com/module/controller/action/key/value, the first thing that apache will try to do is match this against a file or directory, and if it can't find the file then it will send that request to the entrance of zend framework. Now let's assume a URI http://www.example.com/photo-gallery/photo/download/file/someimage.jpg. Let's trace the steps that apache takes to fulfill this request.
- First Possibility: Apache locates the file on the file system and serves it to the client.
- Second Possibility: Apache doesn't find the file on the file system (this is where we do some magic)
- The request is rewritten by apache to index.php
- Zend Framework calls the action FooModule_Photo::downloadAction
- The display action creates the thumbnail for the specified file, then moves the file into the public folder under the same path specified by the request uri.
- The display action either serves the file or redirects to the same URI which now will resolve to an image on the file system.
Now the coolest bit. Let's add some meta data to the file name. http://www.example.com/photo-gallery/photo/download/file/someimage_t100X100.jpg. We can now parse the "file" param in our controller and determine that the client has requested a 100 by 100 thumbnail of someimage.jpg. Seems magical to me.
By adding some reasonable restrictions we have a way to dynamically create thumbnails (update only the view on the next project) and the best part about it is we've simplified our code by separating concerns. Let me know what you think. ~mrBurly