Most of the time I use CodeIgniter ^[1], but there are times when I just need to make a quick change/addition to something which is already up and running.

In an ideal world, this is the no-framework framework I'd like to use one day:

• app
  • controllers
  • models
  • views
  • config (db config, etc)
  • emails (templates for emails sent out by the system)
  • lib (common class files for pagination, db stuff, etc)
• index.php (Front controller)
• .htaccess

In the real world, with deadline constraints, this is how i actually end up doing thngs (however someday I'm going to build the framework I mentioned above):

• app
  • script.php
  • another-script.php
  • yet-another-script.php
  • admin
    • login.php
    • users.php
    • something-else.php
  • inc
    • db-config.php
    • Db.php (Database class)
    • Auth.php (user auth. class)
    • functions.php (functions common throughout the system)
    • ........

Take a look at PHP Fat-Free Framework ^[1]. You don't even need to use it as an MVC framework if you want, but surely you'd want to get into some good programming practice right from the start. It's got a gentle learning curve, compact syntax, fast and powerful template engine, forms processor, CAPTCHA image generator, built-in Javascript/CSS compressor, URL-based caching, easy-to-use SQL handler, and most of all, in a single 55KB file!

My take on this has evolved over 9 years into a set of libraries (not a framework) that I am in the process of publishing: https://github.com/sandeepshetty/pnd

I'm old school and know that good design is possible in any paradigm. I prefer using multiple paradigms and hate being locked into any one (I'm looking at all you OO-for-OO-sake frameworks).

Not much of a MVC fan since it doesn't feel like the right approach to web programming. However, I do believe in separating code from presentation and my approach is heavily influenced by REST and what I like to call Resource Oriented Programming. For me, the web site IS the API.

A note on file structure: I prefer modularity and try to keep my resource handlers self-contained so that they can easily be reused in other projects by coping them. This means that you won't find top level folders like views, controllers or models. Instead, I have top level folders like libraries and handlers (which further contain sub-folders per handler with all the code and templates that it needs).

I use Dingo Framework. Its only 63kb

http://www.dingoframework.com/

application
-config
--deployment
--development
-controller
-error
-helper
-language
-model
-orm
-view
system
-core
-driver
-library
index.php

If you read the documentation (http://www.dingoframework.com/docs) I am not sure what else you really need in a FW?

I found a Simple PHP Framework ^[1]...and it looks like a fantastic "no framework" framework ;)

You might want to check some minimalistic PHP Frameworks:

• Ookuwagata ^[1]
• Simple-PHP-Framework ^[2]
• wephp ^[3]
• LightVC ^[4]

I think they are simple, clean and fast enough.

Any of them will allow to use any model or object relation mapping (ORM) tool (like Propel ^[5], Doctrine ^[6], CoughPHP ^[7], etc...), althought Simple PHP Framework features a basic Active Record based model.

I love building my own framework from scratch, The most perfect framework to me would be something like so:

File Structure

• .htaccess
• index.php
  • /system/
    • /applications/
      • /front_end/
      • /back_end/
    • /libaries/
    • /requirements/

My index.php file would take care of defining certain constants like so:

define('ROOT_DIR',str_replace("\\","/",dirname(__FILE__)));

define('SYSTEM_DIR', ROOT_DIR . "/system");

define("FRAMEWORK_VER","1.0.0",true);

require_once SYSTEM_DIR . "/startup.php";

Simple as that, But within startup.php I would load the following criteria's for my framework:

• SPL Autoloader, to load general classes / interfaces etc.
• Load error checking class and start capturing output, encase some hook pre-sends whitespace
• Create a registry objects to store objects like so:
  • Registry::add('Config',new Configuration_Loader());
  • Registry::get('Config')->system->host;
• Clean all user input such as $_GET,$_POST,$_COOKIE with htmlentites
• Load the route class and generate a route,
  • All this is for is to check for controller/method/param1 or ?c=test&m=test etc.
• Once the raoute is bein found, I will send the route of to the Loader, witch in turns loads the required classes or throws a 404* error page.

when it comes down to the controller, as I have a registry object with a global scope i usually just do the following!

abstract class Controller
{
    public function __get($object)
    {
        return Registry::get($object);
    }
}

and then do like so:

class Controller_test extends Controller
{
    public function test()
    {
        $this->View->title = "Hello World";

        $this->output->send($this->View->compile("test_page"));
    }
}

I tend to never create a template system as PHP itself is a great template system, I usually compose my view system with 2 objects!

First object is the View class witch just has getters and setters for the template data, and then ViewCompiler witch loads the template within the scope of its class like so

class View
{
   //...
   public function compile($template_name)
   {
       $Data = ViewCompiler($template_name);
   }
   //...
}

Then within ViewCompiler:

class ViewCompiler
{
   public function __construct($root,$data)
   {
       ob_start();
            require_once TEMPLATE_DIRECTORY . $root . '.php';
       $data = ob_get_contents();
       ob_end_clean();
   }

   public function location()
   {
       //use func_get_args(), to compile a new Route! and return with BASE_HREF!
   }
}

Then you have a set of functions and helpers all locked in one class for the template system.

I like flourish ^[1]

I made this one ^[1] ( updated development ^[2]) for my own personal use, it consists of only 4 functions:

• DB()
• Route()
• Singleton()
• View()

It's inspired by NiceDog ^[3] and DiBi ^[4]. I use it primarily for simple websites and APIs, and I find the DB() function quite useful because it's quite easy to implement (zero configuration) and supports all the following features:

• SQLite 3
• Arrays for SELECTs
• Last Insert ID for INSERTs
• # of Affected Rows for UPDATEs, DELETEs, ...
• Prepared Statements and Escaping similar to DiBi

I haven't written any documentation for this but it should be pretty easy to understand if you study the code for a couple of minutes.

PS: I only use this "framework" for test cases and sometimes for low traffic stuff, a full featured framework should be used if you're doing something serious.

git clone git://github.com/atk4/atk4.git

echo '<?php $config["atk"]["base_path"]="./atk4/"; ?>' > config.php
cat > index.php
<?php
include'atk4/loader.php';
class MyApp extends ApiFrontend {
    function init(){
        parent::init();
        $this->initLayout();
        $this->add('Menu',null,'Menu')
            ->addMenuItem('index');
    }
    function page_index($p){
        $p->add('HelloWorld');
    }
}

$api=new MyApp('myapp','jui');
$api->main();
?>

Although it's better when things are in their own files, so look at http://agiletoolkit.org/

For hi-end apps with agile toolkit, you would end up with:

• .htaccess and main.php for catchall
• lib/ - for your code
• atk4/ - no modifications inside there
• atk4-addons/ - for some nice stuff you get elsewhere
• doc/ - schema, db updates, don't forget "deny from all"
• page/ - list of pages.
• templates/ - you don't need unless you are making your own theme.
• upload/ - storage for filestore: http://agiletoolkit.org/doc/filestore

For any medium-size sites i tend to go with a good framework that fits the role - CI is usually a good choice.

For small pages, i have my own implementation of an ultra-lightweight (and fast) MVC "framework". It's not really a framework, as all it does is request routing/dispatching but it allows me to have a site structure very similar to, for example, CodeIgniter:

app/
 myMvcLib.php
 controllers/
 models/
 views/
public_html/
 index.php

As for DB abstraction (again, on very small sites) i feel using PDO (using OOP) provides me with enough functionality to get things done, and quickly enough.

I'm making my own framework to use.

I've set standards for the following,

standard datatree multidemensional array

standard way to process get/post data

then I build modules that work with each other and can be combined to make larger programs

e.g. a page program that handles the display of a page with several components.

that uses a html-text component, and image component and even a video component, and can use any other type of content I would want in the future.

the page system works in tandem with a navigation system, and they all work with a version control module.

Each time I build a site I consider how to make it out of reusable modules.

I do the same thing with my javascript functions so as I go I"m building my own framework over time.

I think that I can make decisions about my framework that make them more effective for my use than any prebuilt framework would, because when I build it for myself I can take alot of options off the table, things needed for projects that are outside my core market, that's what makes a custom framework more effective over a generalized one, it can be more specific.

Currently, I maintain two projects built without an external framework. One is my blog, written a long time ago in two days and improved from time to time since then. The code is short, simple, fast and works, but is a bit messy and more complex functionality is hard to add in an elegant way (in fact, it was written to be rewritten as soon as possible, but it works for 4 years now :)). The only external libraries are GeSHi for syntax highlighting and OPT template engine.

Another project is a CMS with a small MVC core. It uses OPT, dedicated form processing tool and PDO extended with caching features and small improvements that speed up the programming. It also will be rewritten some day.

I tend to build a framework for a needed application made up of page controllers, library orientated, using MVC (C being page controllers) and dealing with each request individually. I never use a front controller as its simply idiotic as far as web requests go. The front controller is closer to the user, it's the browser.

If a web project your working on takes off, good luck trying to scale unique requests differently using this (chuckle).

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php [L]

Rant Over :)

I share the same philosophy as above. Any framework must me simple, reusable, and small. Complexity and bloat only compounds the problem. My programming style has evolved to orbit around a single core nucleus of classes that only accomplishes what every web application requires. Handling sessions, making database calls, including javascript and css files, and putting things where they are supposed to go in an HTML page. My own "no-framework" framework of classes can be found at PHP Ease ^[1] where you will find the simplest of solutions to creating web apps that adhere to the DRY, and KISS philosophies. Specifically, check out the Page Class ^[2]. I'll never create another HTML page without using it. Anyone who would do otherwise is only torturing themselves.

I created my own framework called beagleframework. It does basic MVC, but also has you put the core business logic in class files which follows more of the actual OO programming standards. The download is only 180KB and works great for CRUD systems. You can review it at http://www.beagleframework.com

Structure

• bin
• htdocs
• lib

Inside Lib

• beaglelib
• controllers
• classes
• models
• views

I just about never touch php without the use of smarty. This by itself enforces a bit of structure to the app (though not terribly much) and smarty can be put to a tremendous amount of work.

I created a bare bones framework based off CakePHP ^[1] called Vanda PHP ^[2]. The core is 3KB (80 lines of code including comments). It has MVC and OOP but no DBO or REST. Its very useful as a learning process to see how CakePHP hangs together. I've also found it useful for using it as a base to refactor existing spagetti code.

controller.php
index.php
model.php
controllers/
models/
data/
views/