revjim.net

I'm working on an application framework to foster the development of cleaner code and give PHP programmers incentive to do things the right way. When my application framework is complete, I will develop (over time) three modules for it: weblog, gallery, forum.

I really didn't want to reinvent the wheel on this one, but it doesn't seem like anything out there is doing things the right way. PHP SiteManager came close. However, their engine assumes that the underlying structure of everything is HTML. They have special constructs in their code to strip javascript code, and to generate forms. This is not wanted because it doesn't place the flexibility in the hands of the module authors and the website administrators.

Below are my current notes on the design of this system. Comments, and/or assistance are appreciated.

• Applications are made into modules.
• All modules extend the same class which provides core functionality.
• Modules can export Template tags.
• Modules can export mappable functions.
• Template tags are called during runtime while processing a template to gather additional data.
• Mappable functions can be associated with a URL.
• All GET variables are available as $_GET. All POST variables are available as $_POST. All SERVER variables are available as $_SERVER. All COOKIE variables are available as $_COOKIE. (This is standard PHP behavior. These variables will be exported into template space.)
• $SERVER['PATH_INFO'] will be automatically made available in $_PATHINFO.
• When providing parameters to mappable functions through a URL GET, POST, COOKIE, SERVER, and PATH_INFO variables will be made available.
• Mappable functions can assign variables to template space.
• Mappable functions should output something: a redirect, an error, or a template reference to parse and display.

Because of mappable functions and template tags, it is possible that there will be more than one way to do the same thing. For instance, a URL "recent" might be mapped to a function called "core:display" with a parameter of "recent" that merely parses and outputs the given template. This template might call a "blog:recent_entries" tag and use $_PATHINFO[0] to determine the offset. Additionally, a URL "recent" might be mapped to a function called "blog:recent_entries" with a parameter of $_PATHINFO[0] (which determines the offset) and this function might parse a template called "recent". Both of these methods COULD provide the same functionality. However, in the 1st case, the template is parsed BEFORE the engine knows it will be getting blog entries. In the second case, the template is parsed AFTER the engine knows what it is doing. The biggest difference here is that, in the second case, a different template could be used based on the time of day, or the offset of the query. In the first case, this COULD be accomplished with LOTS of logic in template code, where it really doesn't belong.

Example of a template that calls "blog:recent_entries" to produce a weblog:

[html]
[body]
[blog:recent_entries lastn='5' offset='$_PATHINFO[0]' r='data']
	[$data.date][br /]
	[$data.entry][br /]
	posted by [$data.author][br /]
	[hr /]
[/blog:recent_entries]
[/body]
[/html]

Example of the template that is called by the mapped function "blog:recent_entries":

[html]
[body]
[foreach var='blogentries' r='data']
	[$data.date][br /]
	[$data.entry][br /]
	posted by [$data.author][br /]
	[hr /]
[/foreach]
[/body]
[/html]

In the second case, the mapped function, could, say, determine what language the blog being referenced was in, and then call, say, a French template, instead of an English one.

This could be FORCED into the template system like this:

[html]
[body]
[blog:get_lang r='lang' /]
[blog:recent_entries lastn='5' offset='$_PATHINFO[0]' r='data']
	[$data.date][br /]
	[$data.entry][br /]
	[if $lang == "es"]
		es de
	[else]
		posted by
	[/if]
	[$data.author][br /]
	[hr /]
[/blog:recent_entries]
[/body]
[/html]

This last method is considered hackish, and is not recommended.