🎉 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!

A Little More Refined

posted in Rarely Spoken
Published January 02, 2005
Advertisement
Adaptability

Modules
Each module will be registered with the CMS under one or more names. More than one name is allowed to point to the same module so that the module may behave slightly differently for each name while performing the same basic function. For example, a single blog module might support multiple blogs by differentiating them by name. BlogA might use TemplateA while BlogB might use TemplateB. Each could store its entries in a separate table. This prevents code duplication.

Each module must support the following types of functions:

-Content generation
Parameters:
module name - A string representing the name of the module
module parameters - An array of 1 or more parameters for the module. This array contains the rest of the URL as well as a combined array of any $_GET, $_POST, etc. superglobals. The superglobal array will be placed at the 0th index of the array with the parameters from the URL placed starting from the 1st index and continuing in the order that they are written in the URL. A URL of the form http://www.invadersrealm.com/blog/When/Today/ will have this parameter passed as {superglobals, When, Today}

Purpose:
This is the normal function of the module. It creates the content that will be used in the site's main template. For a blog, this would generate the most recent entries or return the result of a search for a specific entry.

-Administration
Parameters:
parameters - A combined array of any $_GET, $_POST, etc. superglobals. This function will be the only function that the CMS will call to manage the module so the module must communicate to itself via these superglobals.

Modules will be initialized by calling include(). For a module's initialization to be successful it MUST return an array giving the names of the above two functions. The name of the content generation function must be at the 0th index and the name of the administration function must be at the 1st index of the array. These two names will be tested with function_exists(); if function_exists() fails then module initialization fails as well.

Module Registration
The CMS must maintain a table that maps a module name to the PHP file that contains the code of that module. The table will be

+-------------------+--------------------+| Name: varchar(16) | Path: varchar(256) |+-------------------+--------------------+


where Name is the primary key for the table. The initial version of the CMS will only require an interface to register and unregister module names; it will not have an interface for uploading new module code nor new module accessory files. Name is required to be unique.

Clean URLs

References:
http://www.alistapart.com/articles/succeed/
http://www.alistapart.com/articles/urls/

->In .htaccess:
Redirect all requests to one PHP file which serves as a distribution point. For ease of use, make this file index.php in the top-level directory of the site (that is, the page that is shown by default when going to http://www.invadersrealm.com/)

->In index.php
Logic

-If the page request is for the main index page show the front page of the site. The front page may be either a specific module or some template text. This option is set in the main administrative panel

-If the request is the real location of a file (one that is not dynamically created) then simply show that file

-Otherwise distribute the URL to the appropriate module. The URL will be exploded at forward slashes and the first member of the array will determine what the which module should be used.

For example, the URL http://www.invadersrealm.com/blog/When/2004/12/25/Article will be exploded as {blog, When, 2004, 12, 25, Article}. 'blog' must be a registered module, if it is not then a 404 page is returned. {When, 2004, 12, 25, Article} are passed as arguments to the module registered as 'blog'. Any $_GET, $_POST, etc. variables will also be passed to this module.

Distribution To Modules

(For extended information, see Modules)

index.php will call the content producing function of the module which has two arguments: module name and module parameters. In the example above {When, 2004, 12, 25, Article} is passed as the module parameters and 'blog' is passed as the module name. If this function fails an error is reported. If the function is successful then the result is placed into the content of the main template.

Security

A function must be made to manage HTTP variables such as $_GET and $_POST as well as the $_SESSION variables. This function will combine these into a single array, and call functions such as stripslashes() based on get_magic_quotes_gpc(), as well as any other procedure that will prevent SQL Injection. This function will be called before any of these variables are passed onto the modules.

A database class will also be created and be made accessible to all modules so that no module need know the database password and login information. The database class will provide an interface for creating tables that will ensure that the tables for each module have a unique name. This unique name will be created by simply prepending the module's name to the name of the table. To query a module's table the database class will also provide a function to get the true name of a module's table (that is the name of the table after the module's name has been prepended to it).

Central User Database

The central user database will only contain a small amount of information about each user. Individual modules may contain their own databases that extend this database. The table for users will be

+------------------------+-------------------+--------------------+------------| ID: unsigned mediumint | Name: varchar(25) | Password: char(32) | Continued...+------------------------+-------------------+--------------------+------------   ------------+---------------------+-----------------+  ...Continued | Email: varchar(256) | Join Date: date |   ------------+---------------------+-----------------+


ID is the primary key and will be auto-incremented. Password is the MD5 hash of the user's password returned by md5(). Email may be used for account confirmation in the future. Join Date is for purely informational purposes.
Previous Entry The Requirements
Next Entry Finally - Some Code
0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
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