I recently added support for Facebook Connect to FlowBasis. Now, user accounts can be linked with Facebook accounts to allow users to log in using Facebook's single sign-in scheme. Currently, the admin needs to associate the Facebook account with a FlowBasis account, but in the not too distant future, users will be able to do that themselves. Users now have three options for account authentication: username/password, OpenID, and Facebook Connect.

I just kicked off the FlowBasis documenation wiki with some information on events. Check it out here.

Any module can now take advantage of the resource ratings and comment systems. Check out core-classes/FlowBasis/Ratings and core-classes/FlowBasis/Comments for the implementations and look to core-classes/FlowBasis/Blogging for an example of how to incorporate these features into one of your modules.

The common question asked of me when I mention I'm building a web framework is, "Why build a new one?". I believe I can provide something of value to the software community, and I believe I need the flexibility of controlling the conventions of the base system to realize my vision. I want to provide a system that easily enables rich interaction between different components on both the client and the server, and I want there to be an expectation of a certain environment available wherever code is being run. Search, ratings, and widgets would be a few possible examples of this type of integration.

Blogs, wikis, and a software release repository would be types of "modules". By software repository, I mean something that would track the latest release of QuoteBlizzard or FlowBasis and know the latest version numbers and download links.

"Modules" tend to contain "resources" that should be searchable and/or rateable. Blogs have posts and comments. Wikis have user created pages. Software release repositories have projects. A developer should be able to create a custom module that tells FlowBasis, "Here are my resources," and FlowBasis should be able to incorporate them into the search engine and provide ratings tracking.

"Modules" also tend to have information that would be nice to easily incorporate into other page views in the form of "widgets". A blog could publish "widgets" for its tag cloud or recent posts. A wiki could publish "widgets" for top-rated pages or most recently updated pages. A software release repository could expose a "widget" that displays the most recent software releases with a download link.

Any page view can incorporate widget panels, and widget panels can be configured through an AJAX-y interface. For instance, you can add a widget panel to your main site page and through the browser (if you have permissions), you can add widgets by browsing through a list of available widget templates provided by modules, or configure existing widgets (such as change the URL on a feed listing widget or change the maximum number of displayed feed entries).

Why am I creating FlowBasis in PHP (as opposed to Ruby or the latest scripting language du jour)? PHP is open-source, and it performs relatively well on shared hosting sites. It's also widely used and has many libraries available for it. That's about it.

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.