A.cc isn't written on my complete CMS engine, but if it might look something like this if it weren't static:

The first layer of tags is just a way to name a block of HTML. The container file could then reference them as {html} and {leftcolumn}.

Or another approach could be:

There's plenty of ways to do it. Obviously you want to keep the template files as close to pure HTML as possible. Sometimes this means creating custom tags that generate HTML that's otherwise hard to represent.

An interface is an empty class:

interface Foo
{
  public function bar();
}

class Bar implements Foo
{
}
// error - it has no function called bar

In a language like PHP, it's more of just a formality. It's just a way to make sure a class implements a set of functions.

I handle them separately just because there's an ideological difference: GET should be used when requesting a read-only page, and POST should be used when pushing data to a read/write page.

But technically there's little difference between them, and they could easily be handled together.

Yes, but I handle it much differently within my CMS. I don't care what URL you submit the POST data to. It's all encapsulated within a POST wrapper request. So my POST request handler looks more like:

function handlePost($post)
{
  if ($post->namespace != 'News') return false;

  switch ($post->action)
  {
    case 'delete':
      // check permissions
      // validate fields
      // perform operation
      // redirect
    break;
  }
}

This is because I don't want the CMS to define the URLs for all the applications it hosts. In short, you make a request with the namespace/action (e.g., News.Delete) along with a redirect URL on success (if wanted).

If you don't redirect and there is no error, then the "GET" request handler would kick in.

http://us.php.net/parse_ini_file

I don't understand your problem. There's nothing stopping any module from handling any request.

A module could do something transparent within the handleRequest (e.g., log to a database), but still return FALSE as to say that it didn't handle the request. Just make sure the Statistics module is loaded first. I treat the INI file as first come, first serve. That's been good enough for me.

There are various ways to solve it. In this particular case, I actually just rolled logging into the main application class. I build my CMS (actually it's a framework with a CMS module) on the fly. So while it may be useful to loop through the modules twice, by first calling a pre-processing function, I've just not had the need to yet.

You can only extend one class.

I do this:

class Module_Foo extends Module
{
  public function bar()
  {
    $app = Application::getInstance();

    // in reality, I rarely make direct calls like this. 
    // usually an object (e.g., DBO_New) is used.
    $st = $app->db->prepare('...');
    $results = $st->getAll();
  }
}

I wanted to avoid using globals, although there's really nothing wrong with it considering PHP's syntax can otherwise get cumbersome (thanks to its retarded scope rules). Or you could create a $this->app variable in the Module constructor.

It's supposed to be "DBO_News." DBO stands for "database object," but it's sort of a misnomer in that it doesn't necessarily have to be stored in the database. There's nothing exposed in the interface that requires it.

Basically a DBO is any conceptual object. It may or may not correspond one to one with a database table.

$news = DBO_News::find($foo); // the constructor is private
if ($news)
{
  $news->title = "A new title";
  // or $news['title'] = "A new title";
  $news->update();
}

It gives me runtime flexibility to only query the data I need. For instance:

$recent_news = DBO_News::findRecent();
foreach ($recent_news as $news)
{
  echo $news->reporter->name . "<br />";
}

The "reporter" isn't actually loaded by the initial query. It's used on demand.

Yes, this generates more SQL than is needed, but I don't care. The reason is that I cache HTML and data objects in memory if needed for performance.

In the above example, the findRecent() will generate a query that returns an array of news items without any linked information. Then for every unique reporter_id, it will load on demand the data for that person. That reporter data is then stored in memory so that the next time the page loads, only one query is run (findRecent()).

This is accomplished by:

The generic find() automatically will pull from memory if it can, thus eliminating simple one-off queries.

Again, this may seem like overkill if you know exactly how you will be using your data. But I chose this design with my templates in mind. I don't know when they will want to use extended information, nor do I want to force the template designers to use some SQL like syntax to inform PHP what to grab.

In this template, no extended data is used or queried:

<ul>
  <li mef:loop="n; news">
    {n.title}
  </li>
</ul>

But it's possible it might look like:

<ul>
  <li mef:loop="n; news">
    {n.title}, reported by {n.reporter.name}
  </li>
</ul>

Or even...

<ul>
  <li mef:loop="n; news">
    {n.title}, reported by {n.reporter.name} who has a game called {n.reporter.projects[0].title}
  </li>
</ul>

The DBO objects live outside of the modules. They can be used with or without the rest of the framework. Module_News "knows" that DBO_News exists, but the reverse isn't true. The other modules probably never need to use DBO_News, but they could if need be.

I don't know what you mean by your include question. (I don't even use includes.)

No. Your include file doesn't execute any code, it just defines functions and classes. If a user accessed it, it would be a blank page.

I'm interested in how thats actually setup, do you place it all in /var/www and have just one virtual host setup in apache? or?

Ah, I figured as much, and the "links" are actual symlinks to the main controller?