<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>David Otton &#187; frameworks</title>
	<atom:link href="http://www.otton.org/tag/frameworks/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.otton.org</link>
	<description>Look! Bunnies!</description>
	<lastBuildDate>Wed, 06 Jan 2010 14:32:48 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Better PHP Project Layouts</title>
		<link>http://www.otton.org/2008/08/13/better-php-project-layouts/</link>
		<comments>http://www.otton.org/2008/08/13/better-php-project-layouts/#comments</comments>
		<pubDate>Tue, 12 Aug 2008 23:21:39 +0000</pubDate>
		<dc:creator>David</dc:creator>
				<category><![CDATA[programming]]></category>
		<category><![CDATA[frameworks]]></category>
		<category><![CDATA[php]]></category>

		<guid isPermaLink="false">http://www.otton.org/?p=202</guid>
		<description><![CDATA[There&#8217;s a post up at PHP::Impact about directory structures for web applications. The recommendations are great for a single project on a single domain, but once you get beyond that I think a different approach is called for. First the quick summary, then the expanded text:

One copy of a library per server, not per project
Use [...]]]></description>
			<content:encoded><![CDATA[<p>There&#8217;s a post up at PHP::Impact about directory structures for web applications. The <a href="http://phpimpact.wordpress.com/2008/08/11/scalable-and-flexible-directory-structure-for-web-applications/">recommendations</a> are great for a single project on a single domain, but once you get beyond that I think a different approach is called for. First the quick summary, then the expanded text:</p>
<ul>
<li>One copy of a library per server, not per project</li>
<li>Use source control and a build script, rather than manually versioning with directories</li>
<li>Put your VHosts file in your <code>config/</code> directory, and link to it with an Apache <code>Include</code> directive</li>
<li>Multiple webroots per project allows for shared code</li>
<li>Switch configuration settings against <code>$_SERVER['SERVER_NAME']</code></li>
</ul>
<p><br/></p>
<p>If you treat libraries as &#8220;children&#8221; of your project you have to maintain a different copy of each library for each project on the machine. Versioning nightmare. A better alternative is to have a single, server-wide location for common libraries, and either place this location on the <code>include_path</code> (our approach), or symlink it to the project&#8217;s local library folder.</p>
<p>Here&#8217;s the standard layout we&#8217;ve thrashed out, which is based heavily on Zend&#8217;s default layout:</p>
<p><code>
<pre>
project/
    application/
        controllers/
        models/
        views/
    config/
        httpd-vhosts.conf
        test.project.com.ini
        www.project.com.ini
        admin.project.com.ini
    logs/
        admin.project.com.log
        test.project.com.log
        www.project.com.log
    admin.project.com/
        index.php
    test.project.com/
        index.php
    www.project.com/
        index.php
</pre>
<p></code></p>
<p><em>Use source control and a build script</em></p>
<p>The key difference is that multiple webroots exist within a single project. In our example we have <code>www</code> (the public-facing site), <code>admin</code> (the control panel) and <code>test</code> (for unit tests). Each webroot contains a front controller, a few static files and some mod_rewrite rules. These sub-domains are held within the same project because they have so much shared code in common (models etc).</p>
<p>The front controller picks up <code>$_SERVER['SERVER_NAME']</code> and uses that to discover/create its own <code>"{$_SERVER['SERVER_NAME']}.ini"</code> and <code>"{$_SERVER['SERVER_NAME']}.log"</code> files, meaning the build script is trivial.</p>
<p>The <code>httpd-vhosts.conf</code> file contains VHost configurations for each site, and is linked with a simple</p>
<p><code>Include /srv/project/config/httpd-vhosts.conf</code></p>
<p>in the <code>httpd.conf</code>. Generating the <code>httpd-vhosts.conf</code> file is pretty much the only thing our build script has to do, but that&#8217;s just a matter of setting paths:</p>
<p><code>
<pre>
&lt;VirtualHost *:80&gt;
    ServerAdmin admin@project.com
    DocumentRoot "/srv/project/www.project.com"
    ServerName www.project.com
    ErrorLog "logs/www.project.com-error_log"
    CustomLog "logs/www.project.com-access_log" common
    php_value include_path ".:/usr/share/zend:/srv/project"
&lt;/VirtualHost&gt;
</pre>
<p></code></p>
<p>There are some additional links on this subject at the end of PHP::Impact post linked above.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.otton.org/2008/08/13/better-php-project-layouts/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
