The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Framework Application Design

Hey everyone. I hope this meandering post is useful and interesting enough for comment though I'm going to admit here that this is were I'm going to set down some of my thoughts on an ongoing project. I've been working on a framework of my own about 2 years now and deployed it to a handful of projects. This approach has helped my coding, shored up weaknesses, and I'm going to spend my unemployed summer refactoring the beast.

My goal is to come out with something that can make small sites profitable, provide clients with reasonable content manipulation without overwhelming them in a sea of options as Joomla and Drupal often have done when I've deployed them.

There are a lot of frameworks out there. My favorite isn't even in PHP - it's dJango and written for python which I have acceptable command over as a language though I don't like it as much as PHP. Certain dJango principles, such as DRY are being ported. It's name as I've mentioned before is PAM, and I am hoping for first Alpha release by end of July, possibly earlier.

The first and most significant difference between PAM and many (most?) PHP frameworks is PAM doesn't live in the ./htdocs folder of the websites it is used on. This is because by design the PAM core code is being designed to service multiple virtual hosts on the same server. The core integrates itself into Apache webserver to some degree - it's installation requires a single line to be added to the Apache webserver's config that points to an includable httpd.conf file.

This approach allows full leverage of mod_rewrite and also allows short_tags to be enabled at the webserver level - meaning that the scripts can ship with the easier to read short tags in use without fear of them not working.

The reason for this approach is to streamline the following macro level approach: Each site that you build with PAM will have a domain. PAM has a setup script for installing a new site - this script must be ran from the command line and further with sudo since it issues a server restart call. The setup script creates 3 subdomains for your main domain -- www.mysite.com, beta.mysite.com, and manage.mysite.com.

The beta and manage shares further are .htpassword protected and PAM handles the password accesses storing the logins for them in the database. Manage is a developer's tool - the client never uses it and honestly doesn't need to be told about it. The manage tool's primary purpose is designing the database layout - in this manner not unlike PHPmyAdmin - but PAM goes a step further and gathers information about how the tables relate to one another, field input descriptions and constraints beyond those which the database itself holds.

This information is used to build the administration system for the site. The concept is this - many, perhaps most sites, can be thought of as data pools with highly decorated reports. The client goes in and makes some pages in a backend that need not be that customized, the focus of customization is in the front facing reports.

Manage will also eventually handle some administrative functions for use with clients - such as disk usage constraints and the ability to shut down a site for payment failure by the client.

Manage's other major purpose is data and code migration between the stable and beta branches of the site. The idea is to take whatever folder holds the beta code and bind it to a subversion repository for further development assistance, while the stable branch has no such underlying process for speed reasons. Manage will also move database data back and forth between these two states.

As mentioned above, PAM places no files in the htdocs folder of the site. This isn't entirely true - there is a lone "landing file" that mod_rewrite points to (though if anyone has a way to get rid of the necessity of this file I'm all ears). The framework is configured to use htdocs as a caching area. This allows this framework to theoretically deliver pages without parsing a single line of PHP, let alone starting the database and incurring that overhead

My goal is to come out with something that can make small sites profitable

vs.

PAM has a setup script for installing a new site - this script must be ran from the command line and further with sudo since it issues a server restart call

I do not know how abroad, but here are "small" sites usually hosted on shared servers - and this requirement points to dedicated ones. But maybe you should state more precisely what do you mean by "small sites".

Precisely what I mean - sites with a handful up to maybe a hundred pages, little or no traffic. Small business sites. The framework is designed for the guy who owns or leases a server then subleases space on that server. PAM is setup to be installed once server wide.

For example, say you have 20 clients and you put them all on Joomla. All of them are running components you wrote yourself, none of those components are exactly the same.

When upgrade time comes do you go to the expense of upgrading the Joomla copy on all 20 sites? What if it's a security issue? What about the unlikely event that a change in joomla breaks a component you wrote? How do you test this? If using a separate dev server do you update the dev copies 20 times then if all works do it AGAIN?

And Joomla averages an update a month. Not to be picking on that particular CMS because the same issue comes up with Drupal, vbulletin, Zen Cart, such that upgrades to the code only typically get done while the site is being upgraded.

PAM changes this by removing code redundancy. Say you have 20 clients. You put all their sites onto the same server that you lease. If you don't have enough clients to afford that you can still use a Virtual Private Server and PAM will work just fine. Now an update comes out for PAM. You install the update to the beta folder. Then you go and test all 20 of your sites or have your clients check over them. Once you're happy with it you use PAM's tools to migrate the beta code over to stable and your done. If you do need to make a change to your custom code it will carry over during the migration.

Hence features can be deployed among all clients and everyone is on the same version of the code because on any given server there's only one copy. If you're successful enough PAM is being written to, at some later date, handle multi-server setups as necessary.

PAM isn't being written like Joomla and Drupal et al where each client has their own copy of the code. Instead the server has a copy and all PAM powered sites on that server use one code copy. In this respect it's like dJango, where only one copy of dJango is installed on the server no matter how many dJango powered sites there are on the server.