mrry is produced, I am ashamed to say, by some very bad PHP, running off a fair-to-middling MySQL database.
I've said before how much I am a fan of Object-Oriented Programming. Even in my old website, much of the layout was standardised using SSI. How come, then, the code for the header of this webpage can be found in rougly seven other PHP files? Along with repeated database logons, and functions that should really be in a library.
All of this is obviously ridiculous, and it's going to change. I know very little about how other Content Management Systems (CMSs) are writted, but I fancy implementing a completely-OO solution.
I figure that the content of a website can be divided into short snippets of text. A "snippet" would be the parent object in the first class hierarchy. From this, I envisage subclasses for static text and dynamically-generated text. The static text could be subtyped further, into articles, comments, trackbacks, even song lyrics.
The dynamically-generated text could be used to display a list of the ten most-recent articles, for example (itself a collection of snippets), or recent comments, or data received from an XML-RPC call. The code would be defined in a table of the database, which would generate a library of PHP classes every time it is updated. Imagine too a system of plug-ins, which could also provide output for inclusion on the page. I have a notion for delivering plug-ins straight into the CMS, using an XML-RPC client that would make calls to an XML-RPC server that would run here. [Two methods: getAllPluginNames and getPlugin(name).] The server could also deliver any SQL that would need to be run (CREATE statements, most likely) for the plug-in in question.
A page itself would be a collection of regions, which would be represented in XHTML as div s, each with a unique ID, and for each of which positioning data would be stored in the stylesheet. Tentatively, I would fancy that the <head>, (physical) top, bottom, left sidebar, right sidebar, and main content area would constitute these regions, though there's no reason why they couldn't be user-defined.
Every page would have an ID, and every article would have a page. My best idea for representing the different types of page would be to have a standard template for each type of page. A template would merely be a set of rows in the database, specifying what snippets should be displayed, in which regions of the page, and in what order. For example, the template for an article would be:
- Standard header at top of page.
- Article content in main content area.
- List of comments for article below article content, in main content area
- Standard sidebar in right sidebar.
- Standard copyright notice at bottom of page.
For the front page, a simplistic template would be:
- Standard header at top of page.
- List of recent articles in the main content area.
- Standard sidebar in right sidebar.
- Standard copyright notice at bottom of page.
However, this rigid templating is (tautologously) inflexible. Therefore, I propose that a page could also be represented by a "non-generic template". For example, say I have an article that includes a Flash cartoon. I wouldn't want to include the cartoon in the article text, because this would appear on the front page, and look, frankly, unsightly.
The solution would be to change the template of this page so that it becomes:
- Standard header at top of page.
- Article content in main content area.
- Snippet containing Flash cartoon, in main content area.
- List of comments for article below article content, in main content area
- Standard sidebar in right sidebar.
- Standard copyright notice at bottom of page.
Therefore, the database would be queried to see if there existed a specific layout for a particular page, before falling back on the standard layout for that class of pages.
The other thing that I want to make possible is the rather-more-difficult proposition of creating a page that isn't a weblog article. At the moment (for me, at least), this necessitates ripping out the necessary HTML and PHP from one of my existing pages, and hastily tapping something out in Notepad. What I'd like to be able to do is sew together some snippets, and I would have a page. I could start from any number of templates, and add, remove, or change parts as necessary. This would give me the utmost flexibility, whilst retaining a consistent architecture.
I'd really like to implement an edit-this-page facility - except it would be edit-this-snippet. A snippet could be edited universally, or only for a particular page. A snippet could be replaced by another snippet from the snippet library. A dynamic snippet could have its parameters changed. A dynamic snippet could also, I suppose, be frozen, so that its dynamic output is preserved for posterity. Obviously, making any change to a template-based page would result in it turning into a custom page.
Is this sounding coherent yet? Never mind if it doesn't - it'll prevent you stealing my crazy idea!
I'd also like to implement the MovableType, MetaWeblog and Blogger APIs, so that my site can be updated from most of the pre-existing blogging software. There would also be RSS feeds a-plenty. I'm thinking (at least) RSS 2.0 feeds for the whole site, each category, comment feeds for each page that has comments, and a statistics feed, which would return information about the recent visitors. I would also look at doing an RSS 1.0 feed (if I can get my head round RDF), and a (not-)Echo feed, if it looks like taking off. However, I would be content to have only the RSS 2.0 feed at first.
There's also a list of features that any weblogging system should have (as pointed to by Gary). I'd like to have all of these as well, with the exception of the import facilities, which I don't view as relevant.
All-in-all it should be quite a substantial project. I'm beginning to write it on my WAMP system at home, and I intend to have a smooth transition - preserving all content, correcting links and minimising downtime - sometime during the Summer vacation.
As ever, your comments are welcome and will be taken on board.
Cheers,
Derek.
|