Location: PHPKode > projects > Thought Push PHP Framework > instance/display/templates/philosophy.php
<style type="text/css">
	.remove{
		color:red;
	}
</style>
<div class="sectionTitle">Philosophy</div>
<div class="sub">
	<div class="sectionTitle" id="philosophy-contents">Contents</div>
	<div class="sub">
		<ul>
			<li><a href="/philosophy#philosophy-preface">Preface</a></li>
			<li><a href="/philosophy#philosophy-introduction">Introduction</a></li>
			<li>
				<a href="/philosophy#philosophy-framework_breakdown">Framework Breakdown</a>
				<ul>
					<li><a href="/philosophy#philosophy-framework_breakdown-main_index">Main Index</a></li>
					<li><a href="/philosophy#philosophy-framework_breakdown-configuration">Configuration</a></li>
					<li><a href="/philosophy#philosophy-framework_breakdown-preloader">Preloader</a></li>
					<li><a href="/philosophy#philosophy-framework_breakdown-display_logic">Display Logic</a></li>
					<li><a href="/philosophy#philosophy-framework_breakdown-display_templates">Display Templates</a></li>
					<li><a href="/philosophy#philosophy-framework_breakdown-utilities">Utilities</a></li>
				</ul>
			</li>
			
			<li><a href="/philosophy#philosophy-instance_system_public">Instance, System, Public</a></li>
			<li><a href="/philosophy#philosophy-page_object">Page Object</a></li>
			<li><a href="/philosophy#philosophy-MVC">MVC</a></li>
			<li><a href="/philosophy#philosophy-request_handling">Request Handling</a>
				<ul>
					<li><a href="/philosophy#philosophy-request_handling-introduction">Introduction</a></li>
					<li><a href="/philosophy#philosophy-request_handling-implementation">Implementation</a></li>
					<li><a href="/philosophy#philosophy-request_handling-thoughts">Thoughts</a></li>
				</ul>
			</li>
			<li><a href="/philosophy#philosophy-controllers">Controllers</a></li>
			<li><a href="/philosophy#philosophy-autoloader">Autoloader</a></li>
			<li><a href="/philosophy#philosophy-templating">Templating</a></li>
			<li>
				<a href="/philosophy#philosophy-coding_guidelines">Coding Guidelines</a>
				<ul>
					<li>
						<a href="/philosophy#philosophy-coding_guidelines-general_efficiency">General Efficiency</a>
					</li>
					<li>
						<a href="/philosophy#philosophy-coding_guidelines-typing_efficiency">Typing Efficiency</a>
					</li>
					<li>
						<a href="/philosophy#philosophy-coding_guidelines-reading_efficiency">Reading Efficiency</a>
					</li>
					<li>
						<a href="/philosophy#philosophy-coding_guidelines-changing_efficiency">Changing Efficiency</a>
					</li>
					<li>
						<a href="/philosophy#philosophy-coding_guidelines-coding_standards">Coding Standards</a>
					</li>
				</ul>
			</li>
			
			<li><a href="/philosophy#philosophy-environment">Environment</a></li>
			<li><a href="/philosophy#philosophy-database">Database</a></li>
			<li><a href="/philosophy#philosophy-sessions">Sessions</a></li>
			<li><a href="/philosophy#philosophy-pluralizing_directories">Pluralizing Directories</a></li>
			<li><a href="/philosophy#philosophy-css_and_js_handling">CSS and JS Handling</a></li>
			<li><a href="/philosophy#philosophy-page_json">Page JSON</a></li>
			<li><a href="/philosophy#philosophy-var_dir_path">Variables Containing Directory Paths</a></li>
			<li><a href="/philosophy#philosophy-naming_system_classes">Naming of System Classes</a></li>
		</ul>
	</div>
	<div class="sectionTitle" id="philosophy-preface">Preface</div>
	<div class="sub">
		Although this page is called "philosophy", on this page, a lot of the time, I am just telling you how I did things and not why I did them.  I did write quite a lot on the philosophy behind the things in this framework, but putting that writing here when even I think most of it was drivel is probably not a good thing.
	</div>
	<div class="sectionTitle" id="philosophy-introduction">Introduction</div>
	<div class="sub">
		<p>
		This framework is a result of my thoughts on what a framework should be.  Although this framework has been around privately since 2007, I have only made it publicly available in 2011; so it might still need some polishing.  From the 3rd version of this framework in 2010, I have made this 4th version based largely on my philosophy of good ways to do things and with the public in mind.
		</p>
		<p>
		It seems that many other frameworks try to hide the language from the programmer.  This leads to a dependency on the framework.  There is a general principle I state, if not follow: Diverge from previous utility only when significantly benefitial.  And so, for the most part, I do not try to hide php; which tends to mean you must have a decent knowledge of php to use this framework.
		</p>
		<p>
		It should be noted that, since this framework has a large basis in philosophy, should my philosophy change, the framework might change drastically.  That is to say, if I find I've been using twigs to drive spikes and find sledge hammers are available, I'd stop using twigs and start using sledge hammers. 
		</p>
		<p>
			There are a couple of things I consider a framework to be useful for:
		</p>
			<ul>
				<li>File location standardization</li>
				<li>Request handling logic</li>
				<li>Database utilities</li>
				<li>Logging</li>
				<li>Session logic</li>
				<li>Template handling logic</li>
				<li>Dealing with CSS, javascript, JSON, XML</li>
				<li>Making available integrated tools</li>
			</ul>
		<p>
			I would not say that a frameworks job is to make available non-integrated tools.  Tools alone, like PECL or PEAR, only constitute libraries, not frameworks.  So, with this framework there are standard places to put tools for autoloading, but non integrated tools are there only for convenience.
		</p>
	</div>
	<div class="sectionTitle" id="philosophy-framework_breakdown">Framework Breakdown</div>
	<div class="sub">
		The framework is broken into various parts reflecting separate concerns.  Here is an example of the sequential control flow of a page request:
		<div class="sub">
			Main Index
			<div class="sub">public/index.php</div>
			Configuration
			<div class="sub">instance/config.php</div>
			Preloader
			<div class="sub">system/preloading/preloader.php</div>
			Request Handling
			<div class="sub">
				system/requestHandling/RequestHandler.php
				<br/>instance/requestHandling/rules.php
				<br/>instance/requestHandling/blog/rules.php
				<br/>instance/requestHandling/blog/post.php
			</div>
			Controllers
			<div class="sub">
				instance/controllers/controller.php
				<br/>instance/controllers/blog/controller.php
				<br/>instance/controllers/blog/post.php
			</div>
			Display Logic
			<div class="sub">
				instance/display/logic/logic.php
				<br/>instance/display/logic/blog/logic.php
				<br/>instance/display/logic/blog/post.php
			</div>
			Display Templates
			<div class="sub">
				instance/display/templates/blog/post.php
				<br/>instance/display/templates/blog/blogPage.php
				<br/>instance/display/templates/fullPage.php
			</div>
		</div>
		At pretty much any point in that control flow, utility functions can be called.  Here is my explanation of these categories:
		<div class="sub">
			<div class="sectionTitle" id="philosophy-framework_breakdown-main_index">Main Index</div>
			<div class="sub">
				This is the file that serves for the immediate and basic setup of the framework.  It is meant to be configured in any sort of non standard use of the framework; for instance, multiple sites running on the same code or running the framework through the console;  If you want to run the framework through the console, you have to replicate the index.php and set the $_SERVER['REQUEST_URI'] variable.
			</div>
			<div class="sectionTitle" id="philosophy-framework_breakdown-configuration">Configuration</div>
			<div class="sub">
				Meant for setting variables based on the instance and the environment
			</div>
			<div class="sectionTitle" id="philosophy-framework_breakdown-preloader">Preloader</div>
			<div class="sub">
				Sets configuration defaults, sets an autoloader, loads user preloaders, and starts the request handler.  User preloaders are loaded after the autoloader and the error handler, and are meant for acting on configuration set in the config.php and for potentially changing behaviors of the framework, like autoloading, which usually have nothing to do with the request itself.
			</div>
			<div class="sectionTitle">Request Handling</div>
			<div class="sub">
				<a href="/philosophy#philosophy-request_handling">See Request Handling</a>
			</div>
			<div class="sectionTitle">Controllers</div>
			<div class="sub">
				<a href="/philosophy#philosophy-controllers">See Controllers</a>
			</div>
			<div class="sectionTitle" id="philosophy-framework_breakdown-display_logic">Display Logic</div>
			<div class="sub">
				Logic intended to reduce the complexity of data formatting from templates and intended to remove complex template choice decisions from the controllers.  Essentially, the controller doesn't need to call a single template so long as the display logic is run and the display logic calls a template; but the way I would do it is to have the controller call one template and have the display logic override that template for any complex conditionals based on <a href="/philosophy#philosophy-page_object">page data</a>.
			</div>
			<div class="sectionTitle" id="philosophy-framework_breakdown-display_templates">Display Templates</div>
			<div class="sub">
				Templates intended to display data an do little more than that.  Any non simple formatting of data should probably be done in the display logic.
			</div>
			<div class="sectionTitle" id="philosophy-framework_breakdown-utilities">Utilities</div>
			<div class="sub">
				There are various scopes of utility functions:
				<div class="sub">
					<dl>
						<dt>General</dt><dd>For just about any php project</dd>
						<dt>System general</dt><dd>For php projects using the framework</dd>
						<dt>Instance general</dt><dd>For any subsequent code within a single instance of the framework</dd>
						<dt>Section general</dt><dd>For any pages within a section</dd>
						<dt>Page</dt><dd>For a page.</dd>
					</dl>
				</div>
				<p>Section and page utilities are someone unique in that they are dependent on each other.  Section utilities are used only by pages and therefore dependent on there being a request; while as for instance, system, an general utilities, the usefuless of the utilities can be completely apart from a page request.  Further, subsections and page utilities are contexted by the sections they are in.  So, as such, I decided instead of having two folders, section and page, with semi identical directory trees, I'd combined the page and section utilities in the same "section" folder.
				</p>
				<p>
					I break utilities into data utilities and display utilities.  Display utilities being a subcategory of data utilities where the data has a small number of, if any, data relations and is meant to be used primarily for direct or semi-direct display.  For instance, rules |defining what conglomeration of template parts to use| can be stored in the database, and a utility can be used for determining from the database what should be displayed.  Although this utility operates on persistent data (from the database), this data is usually not interrelated to much other data and is usually not of much concern to the company.  That is, the company providing a website has data which is essential to the business, such as inventory data, and it has a sort of packaging data which is unnecessary but serves to make the presentation better.  Having the category of display utilities is a convenient way of giving the display category the reach and complexity needed to deal with the database while still be separating from regular business concerns.
				</p>
				<p>
					I imagine, for most projects, however, the display utilities will be relegated to what is often termed "helpers".
				</p>
			</div>			
		</div>
	</div>
	<div class="sectionTitle" id="philosophy-instance_system_public">Instance, System, Public</div>
	<div class="sub">
		<p>The system expects three folders.  Where you put them is up to you, so long as you configure the config.php properly and potentially modify the index.php file.  It is intended that the public folder is set to the apache virtual host root.  The reason from having the public folder away from the instance and system folder is that occasionally, when either apache is under a lot of stress or there is some misconfiguration, apache stops parsing php and just outputs it to the browser.  On these ocassions, it is good to have only things you intended to be public in the web-accessible root folder.
		</p>
		<p>
		I imagine it is obvious why I separated the system code from instance code.  What might not be so obvious is why there are duplicated utility scopes.  The reason for this is that an instance can be using tools which are general in scope, but are not a part of the framework so should probably be kept away from the system folder.  The idea here is that keeping the integrity of the system folder ensures only expected functionality by new programmers to a project using this framework.
		</p>
	</div>
	<div class="sectionTitle" id="philosophy-page_object">Page Object</div>
	<div class="sub">
		<p>The page object is a global object that utility functions write to and display logic reads.  The reason for its being is to limit the amount that the controller has to "know" about both the utility functions and the display logic.  That is, it removes the need for the controller to know what utility functions return and, from that return, what to pass over to the display.
		</p>
		<p>
			I've seen resistance to using globals.  The point of avoiding globals is to make code clearer.  If everything were in global scope, the effect of a function could by on anything and in order to track an unexpected change, all called functions would have to be investigated.  Additionally, if someone wanted to know the intended effect of a function, they would no longer just have to look at the return values of the function.
		</p>
		<p>
			But, when a variable is broadly effectable and potential distant from use, the benefits outway the cons of making the variable global.  So, I have this global page object.
		</p>
	</div>
	<div class="sectionTitle" id="philosophy-MVC">MVC</div>
	<div class="sub">
		You could classify this framework as an MVC framework simply by grouping the parts and categorizing them as either model, view, or controller, but I'll leave that to you.
	</div>
	<div class="sectionTitle" id="philosophy-request_handling">Request Handling</div>
	<div class="sub">
		<div class="sectionTitle" id="philosophy-request_handling-introduction">Introduction</div>
		<div class="sub">
			<p>
			Just with most other things in life, where exactly request handling stops and non-request-handling-categorized code starts is fuzzy.  This, primarily, because "request handler" categorization is an arbitrary categorization of code where a continuous process exists.
			</p>
			<p>
			Conventionally, URLs will statically define a resource in a way very similar to the file path.  That is, directories match and often file names match:
			</p>
			<div class="sub">File:	/var/www/bob.com/music/bobsYodeling.mp3</div>
			<div class="sub">URL: http://bob.com/music/bobsYodeling.mp3</div>
			<p>
			With this conventional URL to file mapping, request handling was simple and could be easily defined as the process of finding the file which needs to be sent or executed; and this process did not have to know anything about what the application did.  As such, you had a model that looked like:
			</p>
			<div class="sub">request handling -> application -> output</div>
			<p>
			Sometimes, in more recent times, URL to file mapping became divergent for various purposes including obscuring and user friendliness:
			</p>
			<div class="sub">
				Obsuring:
				<div class="sub">File:	/var/www/bob.com/music/bobsYodeling.mp3</div>
				<div class="sub">URL: http://bob.com/music/awesomePopMusic.mp3</div>
				Consumer Friendly
				<div class="sub">File:	/var/www/bob.com/loopJsPopup.php</div>
				<div class="sub">URL: http://bob.com/loopJsPopup</div>
			</div>
			<p>
			At this level, the request handler may or may not be a part of the application.  At this level of complexity, It doesn't matter whether the handler is part.  However, this <span id="definition-UFD">URL to file divergence (UFD)</span> can become much more complex.  The complexity comes in what I would like to say is two forms:  
			</p>
			<ol>
				<li>Complexity beyond the functionlity of the web server</li>
				<li>Complexity dependent on the purpose of the application</li>
			</ol>
			<p>
			Both of these complexities lead the request handling within the application code being necessary.  And, since primary distinction between request handling and "application logic" has been lost, there is no longer a distinction and what's left is a cascade of request handling eventually leading to output:
			</p>
			<div class="sub">request handling -> output</div>
			<p>So, given the previous definition of request handling has failed, I will come up with a new one:</p>
			
			<div class="sub">Request
				<div class="sub">The URL and all data submitted to server during a single server "request"/page-load except cookie data.</div>
			</div>
			<div class="sub">Request handler
				<div class="sub">Logic which is primarily concerned with URL path, GET, or POST, and which has no other potential non-request function, and which isn't the "controller".</div>
			</div>
		</div>
		<div class="sectionTitle" id="philosophy-request_handling-implementation">Implementation</div>
		<div class="sub">
			<p>
			Pros and Cons of <a href="/philosophy#definition-UFD">UFD</a>:
			</p>
			<div class="sub">Pros
				<ul>
					<li>
						Allows user friendly paths
						<div class="sub">paths which can be remembered and typed easily</div>
					</li>
					<li>
						Allows for one to many mapping of URLs to pages
						<div class="sub">Allows for generic section pages to be used for request pages that don't exist and don't map to anything</div>
					</li>
					<li>
						Allows context based mapping:
						<div class="sub">
							Mapping based on previous page:
							<div class="sub">"bob.com/register/ -> bob.com/step1", "bob.com/unregister" -> 'bob.com/step1"</div>
							Mapping to a method based on resource attached to request; say, to handle different file types
						</div>
					</li>
					<li>Allows hiding of proprietary file and directory organization (still waiting for my patent request response)</li>
				</ul>
			</div>
			<div class="sub">Cons
				<ul>
					<li>Order of path parts is important.  Order of query string variables is almost never important</li>
					<li>
						Can make finding what a path corresponds to difficult
						<div class="sub">Can make programming harder for newly incoming programmers on to the project</div>
					</li>
					<li>Can make development slower</li>
				</ul>
			</div>
			<p>
			Clearly UFD has considerable benefits.  The next question then is how to implement it.  Primarily, frameworks either use regular expressions rules, and/or page to class method logic.
			</p>
			<p>
			One of the things I have disliked about many frameworks is that fail to use narrowing contexting.  An example of narrowing contexting would be calling more general controllers than more specific controllers like:
			</p>
			<div class="sub">controllers/controller.php</div>
			<div class="sub">controllers/northAmerica/controller.php</div>
			<div class="sub">controllers/northAmerica/usa/controller.php</div>
			<div class="sub">controllers/northAmerica/usa/california/controller.php</div>
			<p>As such, I have the request handler call rules and controllers in narrowing contexting style</p>
			<p>What is actually in the controller is up to the user.  The request handler will only include the file.  I dislike the pattern of having a single file that is a controller class that includes methods which are the page logics.  I don't see the benefit to having this class method to page pattern. 
			</p>
		</div>
		<div class="sectionTitle" id="philosophy-request_handling-thoughts">Thoughts on the matter</div>
		<div class="sub">
			<p>Either the handler knows about the page or it doesn't.  THere is the case that query string variables can be passed to a utility function to determine which page controller should be run.  But, eventually, the page determination just starts replacing controller functionality.  You can have the controller check to see if there was a POST with a certain key, and if there was, perform some action.  Or, you can have the request handler check the POSTs and change the page to a controller which just does that action.  I suppose the way to do it is just to have routing actions, which then call some section controller, which then optionally passes control back to the request handler, which then proceeds to call the next section or page controller.  
			</p>
			<p>	I could make forced separation, such that there are levels of the request handler before it starts handing off control to the controllers.  In such a way where at each token of the url, it looks for another file to load for the mappings.   The benefit of this would be that it would be more clear where things went by looking at just the request handler folder; instead of, potentially, having hundreds of routes in one file.
			</p>
			<p>	Having the routers bounce between controller and route is probably no good, as the interest of the route is different than the interest of the controller.  The controller and section controllers are interested in doing non-route actions.  As such, the request handler will parse the request in some very common way, determine the route, and then call the items in the route unless one of the items tells it to stop.
			</p>
		</div>
	</div>
	<div class="sectionTitle" id="philosophy-controllers">Controllers</div>
	<div class="sub">
		<p>
		I consider controllers to be "page" and "section" logic.  That is, the web request points to something, and if that request points to a script, there is a sort of "page" logic going on when that script is run.  Basically, what a "page" logic is is the logic that translates a user command to one or many system commands.  You might distinguish user and system commands by thinking about the difference between how a programmer might get the system to do something and then how a user might get the system to do something.  A programmer would most likely just bypass the web interface and use the underlying functions.
		</p>
		<p>
		Further, I would argue, and be 100% correct because it is a term I made up, that page logic should contain logic handling the passing of system logic output values to display handlers.
		</p>
	</div>
	<div class="sectionTitle" id="philosophy-autoloader">Autoloader</div>
	<div class="sub">
		<p>
		Before getting into the details of what the framework autoloader does, I'll go into the reasons for an autoloader.  Without an autoloader, there are two things you can do (mixing them is possible):
		</p>
		<ol>
			<li>Load every potentially used resource at start</li>
			<li>Call a load resource function for a resource each time it will be used in case it was not loaded at a prior time.</li>
		</ol>
		<p>
		Without the autoloader, the choice seems to be adding a "require_once" for all resources needed in multiple files.  This leads to many duplicate "require_once" statements.  Pros &amp; cons:
		</p>
		<div class="sub">Cons
			<ul>
				<li>A class/piece-of-code may require different resources depending on which methods/logic-pathways are used; thus, even loading all resources at start of file can be excessive loading; some resources might not be used.</li>
				<li>When a programmer is writing a class method, he will need to remember to write require_once statement for each resource he uses.  Although this seems like an easy pitfall to avoid, when someone gets used to a resource being available in one class, when they start working on another class they might forget that the resource is not already available in that class.</li>
				<li>The laundry list of require_once statements at the top of a class tends to look messy (causes temporary distraction) and can be a hassle to create.</li>
				<li>When a resource is no longer used in the code, the programmer may neglect removing the require_once not knowing that what code he/she removed was the last use of the resource</li>
			</ul>
			Pros:
			<ul>
				<li>The require_once lines at the top of the file make it easy to see what a class or piece of code depends on.</li>
			</ul>
		</div>
		<p>
		The simple solution to this would be to have an autoloader, which, based on the resource name, ensures the resource was loaded when necessary.  The exact implementation of this becomes more complicated when the sources of resources become complex.  But, to forgo the philosophy on my formerly fairly complex autoloader, I have simplified the autoloader so it just checks the utility folders and traverses subdirectories.  If you want to reduce memory, cpu, and file system usage used by the autoloader in finding classes, implement memcached (I might add this as a option in the config).
		</p>
		<p>
		Class files should be named the same what the classes are with the addition of the php extention.
		</p>
	</div>
	<div class="sectionTitle" id="philosophy-templating">Templating</div>
	<div class="sub">
		<p>
		When I developed the first version of this framework I noticed a problem with the templating systems I had used in the passed.  The problem being that the templating systems were commonly used with piecemeal inclusions, like "load(header), load(body), load(footer).   I implemented a russian doll style templating where the inner part of the page would be called first, and then the outer parts; and the content of the inner would be given for placement to the outer part.  I will used an improved version of this system for templating in version four of this framework.
		</p>
		<p>
		The system allows multiple templates to be concatenated at the same level and it allows and template to have any number of templates inside of it to any depth.  Parsed subtemplates become available to the parent template in both the specific form of $templates['TEMPLATE_NAME'] and $input (the concatenation of all the immediate subtemplates).
		</p>
	</div>
	
	
	<div class="sectionTitle" id="philosophy-coding_guidelines">Coding Guidelines</div>
	<div class="sub">
		Concerns:
		<ul>
			<li>Efficiency in typing</li>
			<li>Efficiency in reading</li>
			<li>Efficiency in changing</li>
		</ul>
		<div class="sectionTitle" id="philosophy-coding_guidelines-general_efficiency">General Efficiency</div>
		<div class="sub">
			<p>
			Like in computers, efficiency in people relates to the changeability in function. The most efficient functionality can be found in embedded systems with low changeability. Introduction of a hard drive leads to scanning latency. Similarly, the less diverse a responses someone is expected to respond with, the faster that person will respond. This is for two reasons:
			</p>
			<p>
			For one, there is a period of evaluation - which tool should be used for the problem? The period of evaluation is related to whether there is a quantitative mapping to decisions. For instance, if I knew that all problems of size X were to be solved with A, and all problems with size Y were to be solved with B, then I would have a mapping. This mapping would decrease the amount of time it would take me to determine whether a problem should be solved with A or B because I would not have to try to judge qualitatively and I would not have to construct my own mapping.
			</p>
			<p>
			The second speed decreaser is found in increasing amount of needed recall. If I were given a mapping of types of nails to types of hammers and told to select the correct hammer for each nail of a specified type I received, the time it would take me to select a hammer would depend on the number of mapping elements. If there were only two hammer types and two nail types, I could make the decision fairly quickly; though, not as fast as if there were only one. If there were 50 types, not only would my recall be slower, but I might have to take time to look back at a reference sheet for the mapping.
			</p>
			<p>
			So, by providing a coding standard, mapping is introduced. Further, by reducing the coding standard mappings to the bare minimum that encapsulate all the problems, the need for recall is reduced. By having this minimum mapping, efficiency of typing, reading, and changing is increased. Apart from mapping and minimizing recall, there are some aspects to efficiency particular to the types of efficiency.
			</p>
		</div>
		<div class="sectionTitle" id="philosophy-coding_guidelines-typing_efficiency">Typing Efficiency</div>
		<div class="sub">
			<p>
			Quite simply, the number of characters and the ease of which those characters are typed. Ease of typing is variable among people, so I will simply consider the number of characters to be typed. As such, the characters used should be minimized to the point where further minimization would lead to a higher value loss in reading efficiency. The level of readability is dependent on the code and who is reading the code. If code is intended to be read by anyone, the the use of "function" to describe the language function construct would be needed. If the code is intended to be read by those with a modicum of intuition, the use of "func" would be sufficient. If the intention is for those who are specialized in the language, then "f" might suffice.
			</p>
		</div>
		<div class="sectionTitle" id="philosophy-coding_guidelines-reading_efficiency">Reading Efficiency</div>
		<div class="sub">
			<p>
			Reducing reading error by ensuring the clear delineation of token ends and starts, and the minimization of token ambiguity. Delineation of tokens tends to increase typing. For instance "(bob,bill)" might be typed "( bob , bill )" to increase delineation of tokens. As such, the amount of delineation is determined by the value of decreased typing vs the value of increased delineation. The value of increased delineation is dependent on how much the increased delineation increases clarity. Most parsers ignore white space in situations like "( bob , bill )", and as such, the parse does not need the space delineation to be clear on the meaning. People, on the other hand, tend to be space sensitive.
			</p>
			<p>
			As stated above, readability is dependent on the reader along with the material. This is particularly true because of token ambiguity. To a neophyte, the variable “db” might be ambiguous. To someone used to programming with “db” as a database object variable, the ambiguity is lessened. But, even then, the context of the program might be such that the term “dealing broker” is commonly referred to with “db”, and so, even with someone used to “db” as a database object variable, there may be ambiguity. So, token ambiguity is reader and context dependent. Decreasing ambiguity can be done with standards or with increasing the descriptive quality of a name. Increasing the descriptive quality tends to increase typing, and so this must be weighed. More project specific standards increases the learning curve.
			</p>
		</div>
		<div class="sectionTitle" id="philosophy-coding_guidelines-changing_efficiency">Changing Efficiency</div>
		<div class="sub">
			<p>
			Decreasing dependencies tends to increase the ease of changing something. For instance, many languages allow single statement conditions to use no brackets. If this language feature were used and if someone wanted to change the content of such a conditional to include another line, they would have to add brackets. If brackets were added originally, the dependency would be removed and a change of adding another line to the conditional statement would not require the adding of brackets - they would already be there.
			</p>
		</div>
		<div class="sectionTitle" id="philosophy-coding_guidelines-coding_standards">Coding Standards</div>
		<div class="sub">
			Being as lazy as I am, I decided not to spend the time rewriting my coding standards into html which I originally wrote in plain text.  So, here you have it:
			<pre class="prePageFit">
Naming

	[Camel casing is good, however, there are certain problems.  With words which are case dependent, like brand names, conforming the words to camel casing can make the work ambiguous.  Say, company &quot;grOUp&quot; was the affix to &quot;db&quot;.  In which case, you would have dbGroup.  That this is actually something like dbDell is ambiguous.  &quot;db_grOUp&quot; would not be ambiguous.  However, for the vast majority of variables and naming situations, camel casing is sufficient.  So, my standard is, go with camel casing except in cases where there is significant ambiguity.]

	General
		Try for single word
		Use lowerCamelCase
		
		Abbreviations:
			Use when clear to viewer
			Use for core/common components
			Treat abbrevication as a word
				example: (uid = user identification)
					getUid()
					uidGet()

	Very optional: Another consideration is special consistent naming for certain types of variables.  For instance, if a variable were an array, having that array prefixed with &quot;a&quot; to indicate the variable was an array.  The point of doing this is clarity.  &quot;aBoat&quot; clearly indicates multiple boats.
		Special names:
			- Arrays: affix &quot;A&quot;
				deer, deerA
			- Integers: affix &quot;I&quot;
			- Objects: affix &quot;O&quot;
			

Conditional Structure
	Combine if statements when practical; unless there are many if clauses and separation with commentary would make them more readable
		ex
			bad
				if C1
					if C2
			good
				if C1 &amp;&amp; C2

	Avoid excessive elses; unless it is not immediately clear that the else is not needed, (ie, unless useful for clarity)
		ex
			bad
				if C!
					return true
				else
					return false;
			good
				if C!
					return true
				return false

Spacing
	Tabs
		Use tabs for indentation.
		Do not use multiple tabs to make purely visual alignments. [Code isn't read like columns, it's read per line.  Separating the value further from the variable just makes for more typing and longer scanning]
			ex:
				bad
					hello	= bob
					hi		= sue
				good
					hello = bob
					hi = sue
		Line continuations merit 1 tab
			x = yyyyyyyyyyyyyy...yyyyy
				yyyyyyyyyyy
			if yyyyyyyyyyyyyy...yyyyyyyyyyyy
				yyyyyyyyyyyyyyyyyyyyy
		Items in brackets have one increase in theoretical indentation level.  
				Ex:  (line continuation + indentation)
					x = yyyyy..yyyyy array(array(
								key = value
							)
						)
					x = yyyyy..yyyyy array(
							array(
								key = value
							)
						)
	Spaces
		Use on assignment, comparison, comma separation, ternaries, conditionals
Brackets
	Always use brackets
		ex
			good
				if(bob){
					sue
				}
			bad
				if(bob)
					sue
	Place right after describer.  [Since the benefit of doing it this way is so clear, and since there can be no argument for doing it the other way, I will not explain my reasoning]
		ex
			good
				array(
					key = value
				)
				if(C){
					CODE
				}
			bad
				if(C)
				{
					CODE
				}
				if(C
						C
						C)
				{
	Match ending bracket indentation with theoretical starting bracket indentation.
	Theoretical according to what level of indentation would the starting bracket be if it were on its own line
		ex
			bad
				x = yyyyy..yyyyy array(array(
						key = value
					))
			good
				x = yyyyy..yyyyy array(array(
							key = value
						)
					)
	Curly bracket alignment supercedes line continuation indentation
		ex
			good
				if(C
						C
						C
				){
			bad
				if(C
						C
						C
						){
Foreach
	Except for a foreach construct with around 20 or less lines, foreach assigned variables should be specific.
	In the case where the foreach construct as 20 or less lines, generic variables can be used ($k,$v).  [This based on the programmer decaying memory and attention theory]
		ex
			good
				foreach($bobs as $bob){
					...50 lines
				}
				foreach($bob as $v){
					...5 lines
				}
			bad
				foreach($bobs as $v){
					...50 lines
				}

Variable assignment
	Array elements should only be assigned to variables when: There is a one to many relationship between the variables and the array elements (array as an array of arrays with username, while there is only one $username variable),	and such variables are used more than twice
		$x = array(
				array(username,userid)
				array(username,userid)
				...
			);
		foreach($x as $v){
			$username = $v['username'];
			use $username 3+ times
		}
	However, doing this risks obfuscating the code
	
PHP and HTML
	Use separate indentation levels for HTML and PHP except where php does not take an entire line
		ex
			good
					&lt;div&gt;
				&lt;?	if($bob){?&gt;
						&lt;div&gt;
							&lt;?=$bob?&gt;
						&lt;/div&gt;
				&lt;?	}?&gt;
	
	For multiline php, complete the php tag on a separately line; but try to avoid multiline phpe
	
		ex
			good
				&lt;?	if($bob){
						$bob = 'sue';
					}
				?&gt;
				
				&lt;?	if($bobs){?&gt;
				&lt;?		foreach($bobs as $bob){?&gt;
				&lt;?		}?&gt;
				&lt;?	}?&gt;
				


Comments
	Describe the following line or lines with a comment
		ex
			good
				#checks if user is logged in
				if($userIsLoggedIn){
			bad
				if($userIsLoggedIn){
					#checks if user is logged in
				if($userIsLoggedIn){#checks if user is logged in
	
	In scenarios where putting comments on a separate line than the line of code is either cumbersome or is visually obstructing, place comments on same line ( inline) of code:
		ex
			array(
					'bob' =&gt; 'sue' #I don't like bob
					'bill' =&gt; 'jill' #I like bill
				);
			
			if($x &amp;&amp; $y &amp;&amp; $z
					&amp;&amp; $q #checks q is not false
					&amp;&amp; $z #rechecks z
					&amp;&amp; $g
			){
	...
	
	Which comment indicator to use:  Whichever.
	
	Comment indention
		In some cases comments become complex and have various sections with subsections and the code that a comment applies to is not completely apparent.  As such, I came up with a scheme whereby //+	name { is used at base indentation level with //+	} to show completion of where a comment is relevant, and all subsections follow the same pattern but are indended according to their depth:
			bob()
			//+	sue stuff {
					sue()
					//sue is really bob
					sue = 'bob'
				//+	sue object stuff{
					sue = new Sue
					sue-&gt;sue()
				//+	}
			//+ }
		
		

	Commenting functions: 
		describe the parameters, the return, and a description of the function:
			ex
				/*
				 *	Is a function with the name comment remover followed by some code.
				 *	
				 *	@bob: Array of files to decomment: A(F,F,...)
				 *
				 *	returns success array: A(success=&gt;true|false,error=&gt;S)
				 */
				function commentRemover($bob){...
	
		
	
	Although humor is fun, it does not help to convey the meaning of the code and should be avoided in any type of documentation.
	
	Commenting pages
		If you feel like wasting time, benefiting other developers, than it is occasionally useful to describe what a page is for so that the broad concept of the page is conveyed.  However you want to do this is fine, but I imagine placing the comment at the top of the page is preferable by most.
		
	When to comment
		I find the best time to comment code is 6 months down the line when I'm not sure whether the code I'm looking at is something I coded or my alter ego coded.

			</pre>
		</div>
	</div>
	<div class="sectionTitle" id="philosophy-environment">Environment</div>
	<div class="sub">
		<p>
		Although php applications can be developed on windows, my experience with windows php has shown it to restricted (libraries), inflexible, and generally impractical due to the fact that most servers hosting websites are *nix based.  So, I did not develop this framework to work in windows.
		</p>
		<p>
		Commonly, one code base is used in development and production.  To prevent environment setting code in the code base, the preloader.php grabs the apache set variable "mode" which is intended to be used in the config.php, any user preloaders, and pretty much any code that would change behavior based on the environment.  You can set this "mode" variable in the virtualHost using this line "SetEnv mode development"
		</p>
	</div>
	<div class="sectionTitle" id="philosophy-database">Database</div>
	<div class="sub">
		For the most part, websites use one database.  On occasion, the use multiple.  So, the database class allows for a connection to mulitple database with one being set as the primary and being used by the static calls to the Db class methods.  I used lazy loading and the singleton method for obvious reasons.
	</div>
	<div class="sectionTitle" id="philosophy-sessions">Sessions</div>
	<div class="sub">
		<p>
		Sessions use session keys to verify sessions.  The session key is a sha1 hash of the user agent, ip, and session id.  It is required that this key is saved in the database because it can be fabricated.  That is, if the system only knows the algorithm it needs to match, someone can take a stolen session id and make their own hash of their own user agent, their own ip, with the the session id.  For most purposes, I consider this secure enough.
		</p>
		<p>
		I'm not worried about fabricated packet source IP due to the fact the packets would probably not go back to the fabricator unless the fabricator had a server that was a node in the return path of the response packets to the fabricated IP.  If this is a concern of yours, you are either paranoid or should be making your own framework. 
		</p>
		<p>
		In the case that there are user agent + session id fabricators on the same LAN, well, that's also not a problem I'm going to deal with.
		</p>
	</div>
	<div class="sectionTitle" id="philosophy-pluralizing_directories">Pluralizing Directories</div>
	<div class="sub">
		<p>
		The reason for pluralizing would be to indicate the difference between directories which are mixed categories and directories which are non-mixed categories.  A example of this would be a "scripts" directory containing just scripts, and a "desktop" directory containing a mix of things.  Also, a folder with the name "script" might be describing one script that has many files (another mixed category).  Since there is possible ambiguity I'll name folders that contain non mixed items in the pluralized form: "controllers".
		</p>
	</div>
	<div class="sectionTitle" id="philosophy-css_and_js_handling">CSS and JS handling</div>
	<div class="sub">
		<p>
		In the logic of a page, there can be various additions or alterations to what css and js is included on a page.  Sometimes it is important to have a specific order of inclusion, and sometimes knowing exactly what is included is important.   Potentially, diverse sections of script can modify the inclusions list.  So, I'd say there should be a global list of css and js.
		</p>
		<p>
		Because, at this point in php, in php you can not define special handling for setting a array element (__set is limited), setting css will be done using a function.
		</p>
	</div>
	<div class="sectionTitle" id="philosophy-page_json">Page JSON</div>
	<div class="sub">
		<p>
		The easiest way for php to communicate to javascript is probably by use of a system json object which is passed over to a javascript variable when the page is rendered; or at least that is the way I've been doing it and I'm lazy so it's likely there is no easier way.  So, the Display class has a $json attribute and a getJson method.
		</p>
	</div>
	<div class="sectionTitle" id="philosophy-var_dir_path">Variables Containing Directory Paths</div>
	<div class="sub">
		<p>
		The choice here is whether to end the string with '/' or not.  Useing '/' in the variable pros and cons:
		</p>
		<div class="sub">
			Pros:
			<ul><li>concatenating further folders or files does not take an additional '/', so $folder.$file can be done.</li></ul>
			Cons:
			<ul>
				<li>if the folder name is used for the purpose of finding other things with changes to the folder name, the '/' would be a problem:
					<div class="sub">folder = /var/bob
						<br/>open(/var/bob1/config.php)
						<br/>do something
						<br/>open(/var/bob2/config.php)
						<br/>do something
					</div>
				</li>
				<li>imploding and exploding works better without a trailing '/'</li>
				<li>php functions and constants tend not to include trailing '/'</li>
			</ul>
		</div>
		<p>
		To take advantage of both ways, I will name variables excluding the "/" with the affix "location" and variables including the "/" with the affix "folder".
		</p>
	</div>
	<div class="sectionTitle" id="philosophy-naming_system_classes">Naming of System Classes</div>
	<div class="sub">
		I did not prefix system classes with something like "tp" because I figured if you are using this framework you are probably using system classes.  If you want to swap out a system class, go ahead an do so.  It might be as easy as just changing the order of the autoloader include folders.
	</div>
</div>


Return current item: Thought Push PHP Framework