Firstly, configuration. I mentioned before that I need to identify a policy for what configuration gets stored in the database, and what gets stored in the form of text files. I've since realised that I don't need to do anything fancy just yet. The main problems I want to solve are:

• Create a simple configuration format, even more basic than YAML, but retain the ability to cascade and reference previous nodes (where YAML uses the & and * syntax). This would radically increase parse-time while maintaining minimal file sizes.
• Using the CMS, have the ability to: configure meta data for SEO; choose how to display content (e.g. limit per-page, CSS classes, etc.); and manipulate widget positions.

Being able to change too much on the fly on a busy production environment is far from sensible. WordPress (and many others!) goes for this approach but I'm sure this isn't a problem for 99% of their target market (personal blogs and small-medium business sites). How I personally prefer to work is to make such changes in a safe and private environment, thoroughly test and then explicitly deploy those changes to production. Therefore, for the first version at least, the framework will not provide access to the application configuration via the CMS.

Secondly, I've decided that my URL generation problem is now solved. In addition, all URLs will be 'routed' via a configuration file, including node-based content. That might not make so much sense right now but hopefully it will once things progress.

Finally, and probably the biggest issue I'm still faced with: node storage and retrieval. Tackling the EAV model and maintaining high performance is something that nobody has truely acheived yet - at least I've not come across anything impressive. Doing some (a lot) of research, I've found that Magento is supposidly the most successful attempt at one - yet that's a mess.

The use of the coalesce function in MySQL sounded great. Store all attribute values in a single table and let MySQL pull the right value from the correct data-type column. However, how would you perform searches on multiple attributes in a single query (e.g. SELECT ... FROM ... WHERE age = 50 AND name LIKE 'Fred%'). Don't even suggest multiple select/joins. Unless of course you have a few of these rooms at your disposal.

So I did some more hunting around.

I initially thought Solr would be the ideal candidate. However, I'm still not entirely sure yet how well it can cope with large indexes. Perhaps I can optimise the index by only indexing some content and do full hydration of nodes using MySQL based on the Solr result set (a Solr/MySQL hybrid). Additionally, I don't really like the idea of having dependancies on non-standard services (Solr is a Java application requiring Tomcat, or similar). That's when I found out that Zend had the same opinion. They went and built there own Lucene port, entirely in PHP. Zend_Search_Lucene isn't as good as Solr - it doesn't provide the amount of features I'd like and it's not scalable.

Interestingly enough, I've just found a blog post from July 2008 where the author has suggested a similar system to the one I'm proposing here.

So, next step is to get Solr installed again and start doing some performance testing.

I'll summarise some of the biggest issues left to tackle here...

Node Storage and Retrieval
The framework will be built to support the EAV model. It'll need to be able to store nodes, attributes and a value for each node-attribute relationship.

The biggest problem here is that I don't want to set all attribute value columns to a text or varchar data type (as some frameworks do as a cop-out). I need to identify a schema that allows values to be stored in a column with the correct data type (integer, float, string or binary).

So, how would the framework retrieve all this information without generating multiple queries per node? There are a couple of options weighing up in my head at the moment:

1. Query Solr and rely on that to do all the complicated internal stuff and return me the hydrated node. Can Solr handle this much responsibility? How good is it at storing data for potentionally >500,000 nodes? Could it be relied on by a high traffic web site?
2. Make use of the MySQL coalesce function (thanks to John Wright). The schema would be very straight forward, as would the queries. What's the performance like though? I'd still need to think about how to avoid a huge node_attribute_value table. Perhaps split it up by content type, similar to the CCK module in Drupal?

Right now I'm favouring option two.

URL Generation
The framework will have a category structure which will in turn provide a dynamic menu structure. This allows content publishers to freely create new channels, microsites, etc. and for a link to be placed automatically into the navigation of the site. Easy enough.

However, each node can be assigned to many menu placements (e.g. Featured and News > Sports). One assignment must be made the primary. Each node would have it's own URL slug, the the full URL to the node would be prepended by the category(ies) slug(s), e.g. /featured/my-node.html and /news/sports/my-node.html. This system would allow the same node to appear within several sections of the site, with different URLs. Bad for SEO? Yes. So we'd need to map and use canonical links to point to the primary URL. In addition, we'd need to keep track of previous node URLs to generate 301's if/when a slug changes.

So, how do we store all the URLs for a node? We could simply put all URLs into a table with a relation to which node it belongs to. Would those URLs contain the category slug, or just the node slug? If they contain the category slug, how would we update... I'll stop there. I've just answered my own question: yes, store the category slug as well as the node slug and insert a new row if a slug changes, and set the existing row to 301 to the new row. Sorry if that's not clear, it's there for my own benefit so I don't forget!

Looks like that question may now be answered.

Configuration
There are many types of configuration that the framework will require. From database connection settings to routing and how many nodes to show on a listing page. Only some of this would be wise to make configurable using the database. I need to do some thinking and define a policy here.

There are lots more things to think about too, including exactly how the template system would work. Although on my mind, and considered when thinking about any of the above issues, these are relatively lower priority right now. I'll keep you updated with progress.

Therefore, please add your comments to this post to expand a little on why you chose what framework. This will help me understand peoples needs a little more and may even highlight something that I haven't thought of.

So, go vote.

What I have made available in the Download area is the framework core. That is, without any of the required file structure, applications, etc. It's too early to make all that available.

Although it works, for you to create a project I would need to produce some tutorials. At this early stage, building tutorials would be a waste of time as even the core could drastically change from day to day.

For now, you're getting just a taster of what's to come. Over the coming days/weeks, I'll have something more substantial to offer.

This site is here to provide you good peoples with information about my project-in-development: a PHP MVC Framework. Yes, there are already lots out there, but this is one that I intend to be better suited for my work-related and personal needs than what's currently available.

I'll leave you to hunt around the site to find out more information.