GiriGiriPHP
home | about | download | how to


Flattr this
Current core module and classes in GiriGiri Module loader class/singleton includes/classes/module_loader.php

This singleton is the dispenser of module-action mappings. It creates a module-action map array, starting with the core module-actions (like session), adding the module-action mappings found saved for a page in the database, and finally adding the module-action requests coming from POST or GET.

This finalized m-a array, then is iterated through, and in each iteration, first the permissions are checked for that module-action for the group of the user requesting the page, and, if permission is true, the module/singleton is loaded, and initialized and then action is sent to that module.

This singleton finds out what modules are there, by traversing the modules/ directory and reading the info files (info.php) found in there. These info files contain 2 arrays detailing some info regarding the module (including its directory), and, the action list for that module.

Core functions class/singleton includes/classes/core_functions.php

This singleton keeps various methods that are being used in a number of other core modules. Like, permission check function. Actually, you can use this singleton to drop in any generic methods that may be used in any/all modules.

Db singleton includes/classes/db_mysql.php

This is the current database singleton of GiriGiri. Its methods are for mysql, but it can easily be changed to use another db system.

It carries all the methods that are needed to conduct queries, and also keeps variables to keep state of the query results - whether it was successful, or were there any rows returned and so on.

The power of this singleton is, it can maintain more than 1 connections to a database, and more than one query. If, you send a query like this $db->query($sql,'name'), that query is run and kept in a stash called 'name', always present there and accessible by calling the stash name. Its also possible to ask the class to use a different connection while doing that query.

This allows you to juggle more than one queries on any number of connections. One query doesnt overwrite another, if you need to do so. So, you can keep the states of various queries and their results and success states.

Db singleton also has various methods to fetch results. More can be added.

Variable/globals singleton includes/classes/globals.php

This is a very important singleton. It keeps all the variables that may be needed or used by any module. It not only stores and carries POST, GET and COOKIE, but also carries any kind of other variable that may be needed system wide.

Globals singleton also currently stores the language values, in $gb->lang array. Modules keep their language in sub arrays, like $gb->lang['user']['USERNAMEKEY'], therefore, you have freedom in using whatever key you want in your modules - they wont overwrite any other key in any other module or main page itself. Generic keys for the whole system are kept in $gb->lang['page'] array.

Template singleton includes/classes/template.php

This is also a very important singleton. Template singleton carries page state, structure, the content stashes that are waiting to be placed into the pages throughout all modules.

It can also keep separate structures and the content for them, and build them separately from the main page. These then can be inserted to their places in the main page. Or, they may be for internal use.

The page's main structure is kept in the structure stash $tp->str['page']. Any generic insert or content for placement to the page structure is kept at $tp->in['page']. A module's own template is kept in its own array, like $tp->str['user']. Its stash is kept in $tp->in['user']. In that way, it is possible to have an infinite number of structures and stashes and build them separately from each other, and then add them to each other as desired.

Template singleton also builds the language keys kept in the global singleton into the page at the final building of the page. (or any other structure).

All of the above singletons act as single classes/singletons. They dont act as modules Meaning they dont have separate language, template files for themselves. They are core classes inherent to the functioning of the system. The below, however, are modules.

Session module includes/modules/session

This is the session module. It handles login/logout actions, cookie setting for the login/logout status, and assignment of core user details to user details that is carried in an array in itself.

Though this module is internal, and core, if you desire, you can use another session class yourself, instead of this. But it has to be compatible with the current state of the system, ie, act like a singleton.

This module has few template files and language files. Login/logout forms are currently constructed by this module, but actually they can be constructed by any other module that is run after this module in the running sequence.

Session module includes/modules/session

This is the session module. It handles login/logout actions, cookie setting for the login/logout status, and assignment of core user details to user details that is carried in an array in itself.

Though this module is internal, and core, if you desire, you can use another session class yourself, instead of this. But it has to be compatible with the current state of the system, ie, act like a singleton.

This module has few template files and language files. Login/logout forms are currently constructed by this module, but actually they can be constructed by any other module that is run after this module in the running sequence.

Permissions module includes/modules/permissions

This module manages permissions from admin side, and once permissions for groups are set, its not mandatory to use this module. However, because management of permissions for m-a mappings is important, this module should always be kept. It assigns permissions for

From this point on, modules are not mandatory Despite even the above session module can be dropped, its still more a core module than what follows. Following modules create a usable framework for the GiriGiri system's normal running and management. Their use is to manage the system. If need be, you can drop them all and create your own. Though its not advisable to do so, since they are all coded with the coding logic that was used in GiriGiri, hence, native to the system. In rare cases, like if you need only 1 user logging in and managing the site, you may totally drop user, groups, user_fields modules that manage users. Or, if you have just one or two pages, you can just add them from the pages module, and then drop the pages module.

Pages module includes/modules/pages

What this module basically does is manage pages from admin. Ie, add new pages, add module/action mappings to them. In that, its an internal, important module. But, once the pages and their m-a maps are saved, there is no need to use this module if they wont change for a long time.

The loading of m-a maps is done by the module loader singleton, so, this module doesnt have any relevance in that.

However still, i have designated this module as a core module in module loader singleton's core modules array, and given it the duty of generating generic inserts like header bar and so on. It is an acceptable module to drop all stuff like these into.

So currently, you cant remove this module. But, if you desire to do so, just remove it from the array of core modules in module loader singleton and you are set.

Users module includes/modules/user

This module manages users. The core details of users (like email, username, password etc) are saved in the core user table. This module allows activation/deactivation, editing, adding of users into the system, and assign them groups.

Currently it also handles registrations. It also uses the google's reCaptcha service to prevent spam.

User fields module includes/modules/user_fields

This module manages extra user fields. These fields are generic, and can be added from admin. They are not stored in core users table. Any number of these fields can be added.

Groups module includes/modules/groups

Groups module handles creation/deletion of groups from admin. It doesnt have any other task as of now. Important module, however.

Page constructors includes/page_constructors

Despite not being neither modules or singletons/classes of any kind, the include files that are sitting here handle the shaping of the physical structure of the template of the page by sending/loading structures into the page structure through the template singleton.

First, meta include is run, and it adds the meta template from meta.tpl in templates folder to page structure. Then, header include is run, and it adds body and header of the page. There is a left column include adding a left column, and afterwards, the page content include adds the template for the requested page. (ie, if page=main was requested, main.tpl is loaded). There is a right column addition thats not being used (right_column.tpl is empty but still loaded), and finally the footer.

So, the default way pages were arranged was header, left column, content, footer.

However, this can be arranged in any way you want, by changing these includes. If you wish, you can make a single whopping include, and constitute an entire page from only one .tpl file. Or, if you want, you can make a 3 column arrangement, or, no columns arrangement.

You can do anything. What you use doesnt matter. In the end, its just html/css/javascript in plain .tpl files.