Zend Framework

Tonight marks a minor update to BaseApp, 1.0.0a5. Many users of BaseApp have requested direct support for deploying the archive into a hosting provider where they are not able to have some of the files out of the web space. While the security of this is not as good as having everything except the html directory outside of the document root, it is a common occurrence and not addressing this situation could be more hazardous for some users without proper guidance. This update provides an index.php in the root directory, and .htaccess files in subdirectories to restrict direct code access or access to other files. It is recommended that you delete the html directory if you plan on deploying in this manner, and to read the comments in the index.php bootstrap to better understand this deployment.


Download this update to BaseApp, v1.0.0a5, and get started today!

This entry is about the use of Zend Framework and BaseApp, an application layer built on top of the framework libraries.

One of the things I noticed as I was getting started with the Zend Framework libraries was the smell coming from all of the bootstrap files... a lot of setting of variables, adding directories to this or that, creating various objects for random tasks, and a growing urge to do more and more setup in this bootstrap. This is BAD practice for a few reasons, but here are the two big ones for me:

• Maintainability - did we not learn from php4? Non-OOP code just gets worse and worse over time. It gets unorganized, it gets unfocused, and soon the bootstrap, just like the index.php scripts of old, begin to do too much for their role.
• Reuse - which sounds like a better idea: copying the code over and modifying the section that you want to act differently? or extending a class and only writing new code where its applicable? If you found yourself nodding in approval to the first option, buy this book for good insight into why the second option will make your life much easier.

BaseApp minimizes the bootstrap to a very simple form: set the application path, instantiate the main application class, call any special configuration methods of that object, then execute the main method of the application object. In the included example index.php, this is 5 lines of code. The application object, BaseApp_Loader, handles all of the specific setup that you otherwise see in bootstrap files.

So what about BaseApp_Loader? What does it do? Why is it better than a typical bootstrap?

• XML Configuration - Uses Zend_Config_Xml to load an application level configuration file. Now if you want to launch a second copy of a site, for example, you can use the same exact code libraries and point at different configuration file to use different databases, etc. By using an xml configuration and capturing exceptions through the main application setup process, simple errors like typos won't bring your site crashing to 500 Internal Server Error.
• Method Based Configuration - Each type of configuration is split off into its own method within BaseApp_Loader, so if you want to setup logging to do something other than Zend_Log, or configure database usage differently than the default Zend_DB implementation, you can override the individual method in an extension of the BaseApp_Loader class. Each of these methods receives a Zend_Config object rather than referencing the application's config directly, allowing for easy overrides by subclasses while minimizing the impact of the underlying structure.
• Zend_View Choices - Included in the default implementation are Zend_View and BaseApp_View_Smarty (a Smarty based view). BaseApp allows you to decide what view you want to use in a way that is flexible, and you can add your own if you want (by following BaseApp_View_Smarty as an example, if you need).
• Easy Registration - For modules, views, log control, database control, helpers and more. Utilizing these powerful constructs provided by the Zend Framework libraries is extremely easy using the BaseApp_Loader's methods or overriding them with your own.

Thanks for everyone's patience last week. Some other projects took precedence and I couldn't get as much time into BaseApp as I would have liked. There were some good comments on the last release though, and I'm seeing some good download numbers. I've taken some of those comments and integrated them in; other's didn't make as much sense to carry over into the main source, but thats why this is BaseApp. It thrills me to see people taking it and using it as a quick start for their own application, modifying it to fit their needs. This week has a couple of main additions:

• In previous versions, the authentication functions were commented out as I struggled to decide on what ORM to integrate. I really like propel, but I don't want users of BaseApp to have to have command line access. There are a couple of other up-and-comers, and hopefully they'll get to a stable release point soon. In the meantime, I've implemented auth using the Zend_DB libraries, so at least you can see a sample simple integration of those for adding users.
• Speaking of the auth module, I've also used the user login form to show examples of the power of the Xend_Layout request.
• Finally, I've started an administration abstraction. The main controller for this is AdminController in the default module, and each module reports its own admin functionality. No ACL is in place for any of this yet.

Next version:

• ACL integration into the administrative functionality.
• Example administrative controls using the auth module to add/edit/delete users.

Additionally, check back often for an "Inside BaseApp" series of posts that will be aimed at describing everything from setting up BaseApp to why particular object structures were chosen.

Thanks again to everyone for their continued support. You can grab the latest version from BaseApp Downloads.