[DAMN! I've written a mini-novel]
DB-driven content management systems are all the rage.
I've personally written 3 db-driven content management systems (2 in Perl and 1 in php) and have come to the point where I've an idea that takes a giant step forward (or backwards in some regards). I'm wondering if it's fool-hardy or if it's a plausable idea. I look to you to be my judge and jury ( and hangman :-S )
Lend me your ear and I will spin you a web (site) of files and meta tags...
[ scene fades to black and reappears on a foggy swamp ]
The Idea
The concept is fairly easy to grasp...keep all your corresponding content together.
What I am finding with completely db-driven sites is more work to maintain.
I came up with a mixture db-system / content body in html files but found that when the content was changed, I had to go back into the database to update the various fields: modified date, revised abstracts, etc. This is where I am now.
I'm now at the point where I feel that all this information should be keep in the HTML file...let the author make the changes as needed and pull the values from the HTML files much like you would a database field value.
Layout control is for forums...not for documents (not that you couldn't). The only downside I see is the lost ability to modify site-wide layout control at the drop of a hat. However, I'm willing to lose that capability for a more content-centric system (for my situation).
The current workaround
Being authors, the concept of db content-systems in general is extremely limited (they don't need to know this stuff) and most authors (myself included) rather work in world of WYSIWYG using whatever HTML editor they choose.
I've decided that it is best to let the authors use a skeleton-template layout that would allow them to do straight content-creation (what they are paid to do). They can then save their documents to the appropriate subfolder that coorresponds with their content.
I've already devised the templating system that defines the site identity and controls the main CSS that formats the content to match my scheme. I simply insert the content page(s) into the template via tokens with search-&-replace.
This part all works beautifully.
Expanding on the idea
Once the author places the file into the subfolder, it becomes an searchable entity, much like a record in a database. What I am thinking of creating (or using if someone else has done this), is create a script that would allow me to specify a directory (aka table), file type(s) and start/end search strings (aka WHERE statement). This script would read all the files of the defined types and search all the files for the start and end strings.
Basically, content retrieval from files instead of a database using the start and end strings as 'field names'
At first thought, my idea is to use the META tags as my main area of import. Things like author, creation date, abstract, etc could be placed into a meta tag. I could then search the files for this information and format it out to a layout template (or search results list).
Granted, what I'm looking for works only for small- to mid-sized sites: ~100-1000 pages spread out in various folders. I know that file accessing + searches on a small number of files are practical, but is the time increase over files linear or exponental? I'm assumming somewhat linear (based on similar content lengths).
I'm sure back in the days of old (the 90s), this idea was probably actually used but was dropped due to h/d speed and access times being so bad in favor of the DB.
How bad is h/d access speeds nowadays, really? Especially on specialized rack servers?
What I'm looking for
1) Comments, input, etc. Does this sound sane? I'm really on the fence about this but I want to find a more friendly solution.
2) Code samples. If you know of something like this (doesn't have to be this in a nice little package), or have seen a snippet of code that handles one of the steps described above, drop me some code. You don't need to baby-feed it to me, I've been programming for awhile so I can must likely figure it out.
3) Pros/Cons. Attack my idea...or...embrace it. Let me know what you think. I'm looking for speculation so I know what I 'might' be up against.
TIA
Sean Shrum
