...
We will take a look at the current db design, the way the classes are designed, the way the WWW version works and how it all was reused in the drupal module.
Content
| Table of Contents |
|---|
Decisions made at the beginning
Technologies used
- Smarty (for templating) (http://www.smarty.net/)
- multiple language .ini files to support different languages
- Charisma (WWW layout (uses bootstrap)) (http://usman.it/themes/charisma/)
- Drupal (drupal module) (https://drupal.org/)
How to handle the ingame browser?
- Smarty comes in handy here: The ingame browser loads a different template set as the outgame version (The ingame templates are located in the 'ams_lib' itself). Why can't it load the same templates you might think? The ingame browser uses LibWWW, which supports only a small set of html tags and no css. You can see the allowed set of html tags on the Ingame browser page.
- Smarty comes in handy here: The ingame browser loads a different template set as the outgame version (The ingame templates are located in the 'ams_lib' itself). Why can't it load the same templates you might think? The ingame browser uses LibWWW, which supports only a small set of html tags and no css. You can see the allowed set of html tags on the Ingame browser page.
How to handle #languages?
- In the lib itself there's a Languages directory with multiple .ini files, one for each supported language. The content of these .ini files will be parsed just before loading the template and the part that's needed for the page being loaded will be passed.
- In the lib itself there's a Languages directory with multiple .ini files, one for each supported language. The content of these .ini files will be parsed just before loading the template and the part that's needed for the page being loaded will be passed.
Admins/Mods/Users
- Our current permission system supports those 3 kinds of users, the permission level for this is stored in the db (ticket_user table).
After installing the system there's an initial admin namely "admin". You can login to that user and assign other users as moderator/admin.
- Our current permission system supports those 3 kinds of users, the permission level for this is stored in the db (ticket_user table).
Syncing cron job
- It's perfectly possible that the website is still up even though the shard is offline (crashed, or migrating or what so ever), here 'Synchronizing' comes in play. All new created users or changes to the password/email will be stored in a querycache (db). A sync cron job will run on the server and from the moment the server is back up, the changes will be pushed to the server!
- It's perfectly possible that the website is still up even though the shard is offline (crashed, or migrating or what so ever), here 'Synchronizing' comes in play. All new created users or changes to the password/email will be stored in a querycache (db). A sync cron job will run on the server and from the moment the server is back up, the changes will be pushed to the server!
Mailing cron job
- A mailing cron job is needed to pull new emails sent to the inboxes of our support groups, we use the IMAP protocol to talk with the inboxes. New emails will be processed and actions will be taken (eg: if a new email comes in from a user's email address with no ticket related, then it will create a new ticket for it.). The cron job will also take care of sending outgoing emails, which are temporary stored in the db.
The database structure
Next we started with the design of our database. I had to think about the advanced AMS features in advance. This is the reason why there are still a few unused DB tables in the design, the plan however is to use those as soon as possible by implementing the extra features.
...