GiriGiriPHP
home | about | download | how to


Flattr this
What is GiriGiriPHP about You know, sometimes clients can require crazy things that puts you through a lot of pain to implement, like "Alright, this form is good but i want sprawling daisies popping up in between the email field and rest of the fields, and show different registration fields for people from country x" and so on. Even simple, but quirky things like these may become a pain to develop after some app/website you built on grows large in codebase, even if the initial framework/codebase was very agile.

GiriGiri seeks to avoid this pain by minimizing the tasks any kind of module/insert performs to the extreme, by implementing singleton classes as module cores (each module being singleton), and employing an easily modifiable action structure. Inserting an action to any module is just inserting a switch-case block. After listing it in module info, and giving the action its permissions, it is just ready for using. You dont need to know or tamper with any other part of the module.

Speaking of which, GiriGiri has a very strong and flexible permissions structure. It separates permissions on an action basis, instead of module basis. So, if there are 6 actions listed in a module, each of them can have different permissions. A group may be allowed to use all of them but one, another may be allowed to use just 2 of them and so on. This provides for huge flexibility. For example, you can create an admin group, which cannot use some critical actions you deem risky for them to use. Or, you can create a 'demo' user group, which can see all/any forms and usable content in your website or app, but, disallow them from saving the information submitted from those forms, on a case by case basis. Anything goes.

Girigiri also has a unique page handling logic. You create nonexisting pages from pages manager. Say, a page with key 'contact'. Then you create a simple html file named contact.tpl. Whatever you have placed in this file, will be read and printed in the contact page. Then, lets say you dropped 3 template keys (bracketed strings like {HEYTHISISAKEY}) in it in any place in the html that contact.tpl has. Then, you can go and assign 3 different (or same) modules to page 'contact' with 3 separate actions. And, whenever the contact page is requested, not only the simple contact.tpl will be printed as the content, but also the output of the module-actions that you have defaulted to that page will also be populated into their positions (wherever you put the keys) in contact.tpl, without requiring any kind of specific module-action request in GET or POST.

Module-action concept goes a long way in GiriGiri. Generally, most scripts lump up many modules in one page, and allow you to send only one action to that page. Then, the action, say, 'register' is distributed to the modules that are lumped in for that page. With GiriGiri, there is no such limitation. You can send an infinite amount of module-action mappings in a single value in POST or GET like ms=user-register-mail~stats-save_stat~admin-notify . With that string, for example, register and mail actions are sent to the user module, save_stat action is sent to the mail module, and notify action is sent to admin module.

This kind of request capability makes it easier to reduce module actions to very basic functions, and also reduce the complex, monolithic page structures.

GiriGiri has a genuine template system that totally separates code, html(design) and language. The individual module-action outputs for each module, are also self-contained, with their own templates in themselves, along with their language files. These all can be built separately, and get plugged into places in the page structure. Final structure, content and language is then built at the end of the execution of entire code, and then echoed to the client.

At this point, for example, one may introduce code that sends the gathered language keys to google translate or other translation service, and get them auto translated, and present the page in a totally different language.

Or, if there is no time for a proper modification, one can do a search and replace string operation in the resulting content, and change content of the page before it is sent to the client.

GiriGiri currently uses MySQL 4+ as RDBMS. It can easily be modified to use other database types.

This is a demo site that is sitting on sourceforge.net.

If you would like to download GiriGiri you can do so from visiting project at sourceforge by clicking this link.

If you would like ask about it or get help, you can do so at forum section in sourceforge via this link.