<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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/"
		>
<channel>
	<title>Comments on: Documentation versus Productivity?</title>
	<atom:link href="http://www.procata.com/blog/archives/2005/04/04/documentation-versus-productivity/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.procata.com/blog/archives/2005/04/04/documentation-versus-productivity/</link>
	<description>PHP Programming, Web Development, PHP Advocacy and PHP Best Practices.</description>
	<lastBuildDate>Sat, 11 Feb 2012 14:53:56 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: EViL3</title>
		<link>http://www.procata.com/blog/archives/2005/04/04/documentation-versus-productivity/#comment-8208</link>
		<dc:creator>EViL3</dc:creator>
		<pubDate>Wed, 06 Apr 2005 13:36:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.procata.com/blog/archives/2005/04/04/documentation-versus-productivity/#comment-8208</guid>
		<description>I would suggest this comes down to personal preference, I myself define most of the require_once&#039;s in a single file and then pull this into my MVC&#039;s entry point, this way all classes are instantly available without the worry of maintaining dependancies.

Depending on the project this could be anything from 10 to 100+ includes, and before any of the hardcore-speed-freaks scream how wasteful this is, the overhead of pulling in so many classes can be drastically reduced by using a Cache system such and EAccelerator or Zend Accelerator.
</description>
		<content:encoded><![CDATA[<p>I would suggest this comes down to personal preference, I myself define most of the require_once&#8217;s in a single file and then pull this into my MVC&#8217;s entry point, this way all classes are instantly available without the worry of maintaining dependancies.</p>
<p>Depending on the project this could be anything from 10 to 100+ includes, and before any of the hardcore-speed-freaks scream how wasteful this is, the overhead of pulling in so many classes can be drastically reduced by using a Cache system such and EAccelerator or Zend Accelerator.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alan Knowles</title>
		<link>http://www.procata.com/blog/archives/2005/04/04/documentation-versus-productivity/#comment-8189</link>
		<dc:creator>Alan Knowles</dc:creator>
		<pubDate>Wed, 06 Apr 2005 05:30:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.procata.com/blog/archives/2005/04/04/documentation-versus-productivity/#comment-8189</guid>
		<description>The article acheived it&#039;s aim, in that it encourages coders to think carefully about when and where to put your require_once&#039;s. In a totally OO patterned framework, you probably have a base action class, for a particular module or site, which can load up common libraries that are required. So it is likely you end up with a single require_once on the action page, the inclusion of the base class. Which in turn pulls in some of the more critical libraries (Database tools / Template Tools etc.). Other components (like task specific libraries) are often best moved right next to the location they are used.. the line before the class is first instantated..

As my own mini-framework has evolved, the amount of libraries autoloaded at the start has been reducing, rather than increasing, moving alot of the responsibilities to the page action base classes, or directly into the code flow.. </description>
		<content:encoded><![CDATA[<p>The article acheived it&#8217;s aim, in that it encourages coders to think carefully about when and where to put your require_once&#8217;s. In a totally OO patterned framework, you probably have a base action class, for a particular module or site, which can load up common libraries that are required. So it is likely you end up with a single require_once on the action page, the inclusion of the base class. Which in turn pulls in some of the more critical libraries (Database tools / Template Tools etc.). Other components (like task specific libraries) are often best moved right next to the location they are used.. the line before the class is first instantated..</p>
<p>As my own mini-framework has evolved, the amount of libraries autoloaded at the start has been reducing, rather than increasing, moving alot of the responsibilities to the page action base classes, or directly into the code flow..</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sencer</title>
		<link>http://www.procata.com/blog/archives/2005/04/04/documentation-versus-productivity/#comment-8081</link>
		<dc:creator>Sencer</dc:creator>
		<pubDate>Tue, 05 Apr 2005 06:42:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.procata.com/blog/archives/2005/04/04/documentation-versus-productivity/#comment-8081</guid>
		<description>Wether you are doing includes, auto_prepend, explicit Frontcontroller by rewriting every request to a single script - I see it all only as a matter of syntax. There is no inherent superiority with either appraoch. Depending on how all the other code looks, some people may be more comfortable with one over the other, but that boils down to a matter of personal preference. IMHO.

&gt;C is a little more complex because it has to dispatch to A and 
&gt;B, but when A and B are really A-Z, the dispatch price fades 
&gt;away.

I am not sure I understand what you are saying here. Is it easier to add lines to the frontcontroller than to the file that would otherwise have an include-statement?

&gt;Should you put a require_once at the top of every file for &gt;each dependency it contains? 

No, I think most people would just require one file that takes care of including all the other necesary ones.

&gt;I think the state of the art is going in a different &gt;direction, towards containers, front controllers, and &gt;dependency injection.

I agree, but I think it&#039;s because it fits better with the (meta-)language that most people speak, it&#039;s neither new nor  different from what people were doing before the knew the words or concepts of container, front controller and dependency injection.  </description>
		<content:encoded><![CDATA[<p>Wether you are doing includes, auto_prepend, explicit Frontcontroller by rewriting every request to a single script &#8211; I see it all only as a matter of syntax. There is no inherent superiority with either appraoch. Depending on how all the other code looks, some people may be more comfortable with one over the other, but that boils down to a matter of personal preference. IMHO.</p>
<p>&gt;C is a little more complex because it has to dispatch to A and<br />
&gt;B, but when A and B are really A-Z, the dispatch price fades<br />
&gt;away.</p>
<p>I am not sure I understand what you are saying here. Is it easier to add lines to the frontcontroller than to the file that would otherwise have an include-statement?</p>
<p>&gt;Should you put a require_once at the top of every file for &gt;each dependency it contains? </p>
<p>No, I think most people would just require one file that takes care of including all the other necesary ones.</p>
<p>&gt;I think the state of the art is going in a different &gt;direction, towards containers, front controllers, and &gt;dependency injection.</p>
<p>I agree, but I think it&#8217;s because it fits better with the (meta-)language that most people speak, it&#8217;s neither new nor  different from what people were doing before the knew the words or concepts of container, front controller and dependency injection.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lucas Carlson</title>
		<link>http://www.procata.com/blog/archives/2005/04/04/documentation-versus-productivity/#comment-8042</link>
		<dc:creator>Lucas Carlson</dc:creator>
		<pubDate>Tue, 05 Apr 2005 04:08:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.procata.com/blog/archives/2005/04/04/documentation-versus-productivity/#comment-8042</guid>
		<description>Are you familiar with Ruby on Rails? http://rubyonrails.org/

It uses dependency injection and front controllers very nicely.</description>
		<content:encoded><![CDATA[<p>Are you familiar with Ruby on Rails? <a href="http://rubyonrails.org/" rel="nofollow">http://rubyonrails.org/</a></p>
<p>It uses dependency injection and front controllers very nicely.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

