JSON stands for JavaScript Object Notation, and if you dig through the source, you'll quickly realize that JSON is the preferred format of choice for FlowBasis. JSON is easily usable from client-side javascript or within PHP on the server. It's the format objects are transmitted in from the client to the server and back again for remote procedure calls (AJAX stuff), and it's the format of objects saved in the FlowBasis object store.

A sample JSON object declaration might look like (in Javascript, the quotes aren't required around "username" or "favoriteNumbers"):

{ "username" : "bob", "favoriteNumbers" : [42, 37, 100] }

In PHP, this could be declared as:

$bob = new stdClass;
$bob->username = "bob";
$bob->favoriteNumbers = array(42, 37, 100);

and it could be converted to JSON with:

$json = json_encode($bob);

But, usually, the FlowBasis infrastructure will convert the PHP object into JSON where needed.

All requests to a FlowBasis site are routed through the route.php file (via mod_rewrite) which sets up the FlowBasis environment and hands off the request to the routing manager (FlowBasis_Routing_RoutingManager). The routing manager finds the appropriate request handler for the request URI and passes off the processing to it.

The three basic types of request handlers are:

• Basic file handler
• Page request handler
• Site path request handler (extensible handler model used by modules)

The basic file handler is for requests that map to a static file (html, png, gif, javascript, css, etc) and just returns the file contents.

The page request handler kicks off the page processing model (see a future post for details on that).

The site path request handler system is used by modules (blog, wiki, etc) to register for requests to particular URIs. Custom site path request handlers can also be created by developers interested in doing something completely different with a request.

The process of selecting the appropriate request handler goes through a series of steps, which essentially boils down to picking the request handler that is interested in the longest prefix of the request uri.

Consider the following scenario, where a user makes a request to get http://test.calevinci.com/flowbasis/someblog/img/hello.png.

Let's assume the following:

• FlowBasis is installed in /var/www/flowbasis (and test.calevinci.com maps to /var/www). This means that /someblog/img/hello.png is the site path. /flowbasis is the request URI root.
• The file /var/www/flowbasis/pages/someblog/img/hello.png exists.
• A blog module is set up and registered with the site path someblog.

The routing manager will look in several places for possible matches. It will look in the pages and core-pages directories for files and pages (core-pages is for the FlowBasis infrastructure, and sites built on FlowBasis should use pages). The routing manager will also look at registered site path handlers.

The basic file request handler will want to process the request with a matching site path of /someblog/img/hello.png. The module site path handler will want to process the request with a matching site path of /someblog (with an extended site path of /img/hello.png). The basic file request handler has a longer matching site path, so it wil get to process the request.

Now's let assume the user makes a request to get http://test.calevinci.com/flowbasis/someblog/tags/trees.

No file exists at either /var/www/flowbasis/core-pages/someblog/tags/trees or /var/www/flowbasis/pages/someblog/tags/trees, so the module request handler will get the request with a matching site path of /someblog and can map the extended site path of /tags/trees to a page with recent posts tagged with trees.

FlowBasis supports the use of OpenID for logging in. Users can go to their account profile page to associate an OpenID identifier with their account and from then on, they can sign in using the OpenID login system.

Rather than rely on a SQL server for tracking users, blog posts, and such, FlowBasis uses a JSON object store for persisting, retrieving, and updating objects (see FlowBasis_Data_FileObjectStore for implementation). Relational databases have any number of niceties, including being well-understood, well-tested, and providing a known structure for data. However, databases are frequently very slow in shared hosting environments and mapping the objects we tend to use as programmers to relatational tables can be tedious. While the merits of SQL databases versus the free-form object store could be debated at length, I'll leave it at that for now.

The object store provides a few basic methods: getObject, saveObject, and updateObject. Beyond that, there are a few additional methods for retrieving lists of objects and locking objects for synchronization. The default implementation of FlowBasis_Data_IObjectStore saves and loads everything to and from the file system, but the door is open for future implementations which use a database or the "cloud" for storage (though I imagine more intelligent use of caching would become necessary as the object store moves farther away from the local server).

All that said, if you really want to use SQL with FlowBasis, you're welcome to use it. FlowBasis incorporates the open-source adodb library and provides a management panel for configuring connections and trying out SQL queries.

Just to summarize a few general concepts available within FlowBasis...

• Pages can contain controls which can contain other controls.
• Pages and controls can communicate from browser to server via remote procedure calls (JSON-RPC).
• Modules (blog, wiki, etc) contain resources (posts, comments, pages, etc).
• Resources are indexed for searching.
• Modules (blog, wiki, etc) or other sources can publish widgets (recent posts, tag cloud, html snippets) that can be embedded in other pages.
• Resources can be rated.
• Anything can publish events to the event manager. Anything can subscribe to events with an event handler.
• Task handlers can be registered to perform tasks that must be done periodically in the background (like cleaning cache).
• Installers manage adding and removing features/modules/whatever from the system.
• Permissions define what users can do within modules (such as post an entry to a blog).
• Users can have roles which grant them permissions (such as only admin and author could post an entry to a blog).
• Roles can apply to specific contexts (user can be admin for whole site or just a particular blog).
• Themes collaborate with pages and controls to determine the visual style of the site.

There are a few ways to add your content into a FlowBasis based site.

• Add a file (regular old PHP, HTML, png, gif, whatever) within the "pages" folder.
• Add a FlowBasis_UI_Page declaration in a PHP file with FlowBasis::setPageClass('NameOfPageClass') within the "pages" folder.
• Use one of the built-in modules (currently blog and wiki).
• Create your own module class.
• Register a site path request handler with the routing manager and use your imagination from there.

Over the next few days, I'll try to make a series of posts to give the general idea of what you can do with FlowBasis, so stay tuned...

FlowBasis the new PHP web framework I've been working on. The source is available on sourceforge.net. It's still very much a work in progress, but this site is now running on the platform.