🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

The Requirements

posted in Rarely Spoken
Published December 25, 2004
Advertisement
Merry Christmas everyone!

For this entry I'd like to describe the CMS I am planning on building. This will be the requirements that this project is designed to fulfil.

The Core CMS

Adaptability
My primary concern is that my system be flexible and scalable. I really have no idea what direction my site is going to take in the future so I would like to ensure that I can update this system quickly and easily. I believe it would be best if each application of the site (that is blogs, file databases, photo galleries, etc.) could be independent of the others and that the base CMS should not be dependent on any one application's existence.

In order to fulfil this requirement, the CMS should be able to accept and manage modules that describe an application. Each module should be a self contained set of code and auxiliary files that should have access to the shared resources of the CMS (such as the database). This will allow me to develop the site in parts: first the core CMS and then the individual modules.

Clean URLs
I want my URLs to be nice and clean, no ?module=blog&year=2004&month=12&day=25&item=TheRequirements junk at the end but rather blog/When/2004/12/25/TheRequirements, like at ongoing. That way I can change the underlying structure of my site as needed without breaking others' bookmarks. Further, this would make the URLs a bit easier to remember.

Security
Since my site is important to me I'd like my CMS to be as secure from SQL injection and other hacks that could damage it or the users of the site.

Global Template
The CMS should support a global template for the site that would be placed in as few files as possible to allow for very quick visual modification of the site. The template will define the global navigation, header, footer, and layout. Each module will produce the content of this template.

I have yet to decide if a module should be allowed to override the template. I'm leaning towards, no.

A Central User Database
One of the shared resources my modules should have is a central user database. This would store various information about the users (email, password, hometown, interests, etc.) so that each could have a profile but would also maintain their level of access to the site. There should be a privilege flag for each user that determines the actions the user can perform, such as create resources on the site for modules that allow such things (a created resource could be a comment on the blog).

One problem I haven't worked out yet is how modules can maintain their own options for the users. For example, what it a forum module wanted a GD-like rating system, how would the module be able to store ratings? If I could find a way to work this out it might replace the flag the privilege flag mentioned before.

The Base Modules

These are the modules I currently have planned that should be enough to recreate my site as it is currently

The Blog
The blog should support the addition, deletion, and modification of enteries. I should be able to give an entry a specific post date (so that it can be something other than the current timestamp) and a last-modified date. Each entry should be able to be inserted into one or more categories where categories are easily created. The entries may then be searched by category or by post time (where post time is organized by original post date, not the last-modified date).

Comments should be supported and should also be able to be disabled for individual entries, categories, or globally. Anonymous comments will be supported although may be disabled. There should be a way to close entries to comments after a certain interval of time.

HTML should be disabled in the entries as well as the comments in order to ensure XHTML validity. Instead, some sort of BB code should be implemented that can be extended as needed.

Links Database
There should be a links database that stores links in one or more categories, have a title, and a short description. This module will support the searching and organization of these links.

I want this module because I find it difficult to manage my links now. I try to categorize them but some fit in multiple categories and others dont seem to fit well in any category I have created. I really dislike duplication of links on my static pages because it makes it difficult to remove all instances of it if I find that the site is no longer up or no longer what it used to be.

Downloads Database
Similar to the links database, this module will support the organization of downloads. Each download may be in one or more categories, has a title, description, and option of a screenshot.

Photo Gallery
Since I plan on having a lot more photos on my site I would like a module that is able to organize and present them as well in a similar manner as the downloads and links databases.
Previous Entry A Long Absense From GD
0 likes 4 comments

Comments

Colin Jeanne
Do you think giving each module a UID and providing a way to query all modules would be a good system? I was already planning a system where a module would be need to be registered with the CMS before it could start functioning; this process could assign a UID to the module as well as associating a name with the ID. Each module will be required to access the database through one database class so that no module need know the password of the database or any other information, in the operations to access module-specific tables this database class could prepend the UID to the name of the table to ensure that each table has a unique name. This would be done when creating a table


/*Creates a table logically named 'comments' for module 'blog'
  The table would actually be named '1_comments' assuming the module's UID is 1*/
DB->create_table('blog', 'comments');



Another function could be created that allows a module to access the true table name. Perhaps like:


$table_name = DB->get_name('blog', 'comments');
/*$table_name now equals '1_comments'*/


A module would be required to use this table name in order to perform queries.


DB->query("SELECT * FROM $table_name WHERE user = $user_name");



A second module could then access the tables of 'blog' as long as it knew the names of 'blog's tables (before the UID was prepended). It could just use DB::get_name() to get the real names of the tables for one or more modules and use JOIN.

The second module could know the name of the blogging module through configuration by the administrator.
December 28, 2004 01:54 AM
Colin Jeanne
I interpreted the U to mean 'unique' ID for the modules, yes. Although the system does give each user a unique ID as well. For the module IDs, it might only be necessary to use the name of the module as the ID. The way I am planning on having the system work is to break the URL into the parameters for the module, one of these parameters is the name of the module to be used. For example, we'll say that I have a module whose ID is 'blog', I could access the module by the URL

http://www.invadersrealm.com/blog/When/2004/12/28/A_Post

The clean URL code splits the URL into an array of the 'directories' so that 'blog' is the first index, 'When' is the second, etc. The CMS will then find the code registered under the name 'blog' and then pass the array of these directories to that code. I have a test implementation of the clean URL system up here. Typing in something like http://www.invadersrealm.com/cjnet/A/Random/Directory/A_File will just print the URL after it has been split and after the name of the module has been extracted. The system also correctly opens the file http://www.invadersrealm.com/cjnet/test/variables.html

As for the central database, after further thought I decided to only include a user ID, an MD5 hash of their password, their name, and their join date since these seem like they would apply to any module that needs information about users.
December 29, 2004 03:37 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement

Latest Entries

4E6 PyGame

1404 views

4E5

1138 views

Happy Yesterday!

1093 views

Another Game

1305 views

Merry Christmas!

1073 views

Hello There

1072 views

Yay!

1088 views
Advertisement