If you decide to give My Framework a try and make a web application with it, knowing where everything is in your application might be (very) useful. You can already get a sense of this by looking at the tutorials, but here's a more detailed description.

As with every application based on a framework, your new My Framework application will have a specific directory structure. Not all of these files and directories are required, but I think they will be needed at one point or another in your application's life.

To get started with a new application you can simply checkout the "application skeleton" from our SVN server. Go to your public Web area on your server and assuming you're on a Linux console type:

svn export http://my-framework.com/svn/phpapplication/1.x/trunk test

This will create a directory named "test" containing your new application. You'll see the following:

app/
- this is where all your scripts will be

common.php
- this is the first application-specific file to be loaded by the framework

configs/
- all your config files live here

db.create/
- this is not really needed, but it's good practice (at least in my case) to have all your database schema in separate files (one for each table) located in this directory

include/
- all your classes and other include files will be located here; if you create a class User and place it here in a file User.class.php, you don't have to specifically include this file in your scripts because the framework will load it automatically when you use an User object

LICENSE
- not really needed, only if you want to provide a license for your new application; this is initially empty

my-framework/
- this directory contains the My Framework core files

README
VERSION
- these 2 files are initially empty, use them as you wish or just delete them if you don't think they're useful

views/
- this is where your view files live; every script could have one or more view files associated with it, or even no view file at all (think AJAX scripts)

web/
- this directory is where you should place all content that should be accessible from the Internet; actually, this is the only folder that needs to be placed in your public web area and it contains the front-end controller, images, CSS and Javascript files

In part 2 of these series we'll look at how this new "test" application is structured logically and how each of these files and folders that we've seen so far fit together. I'm looking forward to your feedback or questions in the comments section.

Different developers have different needs when it comes to the framework they choose, so I'm not sure what is important to you, but I can talk about what's important to me in a framework. The core of "My Framework" only contains what I consider the basic and most important features, while everything else is or should be added through plugins, extensions or application modules (more about each of these in another post).


Routing System

A framework needs to decide what logic (or script) needs to be executed when a request is received. It needs to translate from URLs to actual scripts in your application. In "My Framework" this is done using a set of pre-defined rules which govern how URLs of your application are translated to the appropriate scripts, but if this is not enough, you can also define your own rules which take priority over the defaults.


DB Interface

Almost all applications need a database so database support is very important for a framework. Some frameworks place a complex ORM layer between the application and the actual database and try to restrict as much as possible direct database access. Usually in these cases, the framework also provides some "generator" scripts that will create your model objects based on the database structure (and of course, you'll need to re-generate these models any time you make a modification in your db). You might argue this ORM-only-access is desirable in almost all cases, but for highly optimized applications this won't work.

My Framework has some kind of ORM layer, but no generators, because they are not needed, and direct database access is very easy. This allows you to combine the ease-of-use of model objects with the occasional direct DB access which doesn't require or create any ORM objects.


Validation

Data validation is very important in every application and especially in web applications. It's also something very boring to do and I would think not many developers would want to write data validation code too much or too often especially when it's about the same from one application to another.

My Framework contains an automatic validation system that works both on client side and on server side. The validation rules are defined in a configuration file on the server and are used to perfom automatic validation when:

- a web form is submitted (client side, Javascript validation)
- data is inserted or updated (in the database) via the model objects (server side validation)


Extensible Architecture

By this I mean a way to create plugins or similar components for the framework. In "My Framework" plugins are used to add functionality to the framework and/or the applications created on top of it. You can also create extensions, which are used to modify certain parts of the framework. For example, Smarty support (for the views) is implemented as an extension, while the session support is implemented as a plugin.


Different Contexts

In most cases, at least in web applications, the request comes from a browser and the output generated by the application is printed to the "screen", which is again the browser.

However, this is not always the case and you might find yourself in the situation where the request comes from an AJAX call, or via function calls from another application. All these represent different contexts in which your application receives the request and although the output might be the same regardless of the request, the delivery mode to the requester will change.

At the moment, My Framework supports 3 contexts:
- web, the default, in which case the output is printed to the browser
- ajax, for AJAX requests, in which case the output is encoded in JSON and then sent to the browser
- code, used when your application is embedded into another application, in which case the output is returned to the caller (just like the return value of a function)

Using these different contexts, the same application created with My Framework will work in very different scenarios: as a standalone (web) application or embedded in another application (for example as a plugin for Wordpress) or as backend for a Flash front-end. All of this would be possible using the same base code.



Of course, the core of My Framework contains a little more than what's above, but I think these represent the most important aspects of the framework. Anything else can be added by creating new plugins, extensions or application components.


One of the most important goals for My Framework is to keep a small core, that is fast, flexible and with as little overhead as possible in terms of resources consumed by the applications built on top of it.

Welcome to My Framework's brand new blog!

This framework lacks one very important ingredient: documentation! But until this is created and published online I've decided to start this blog and post articles on specific "how-to" topics that you'd normally find in the documentation. All these posts will eventually be part of the framework's documentation and my target is to post one such article every 2 or 3 days.

Your feedback and comments will be appreciated! Thanks!