Home

What's is under the hood of ConKit

We used several approaches which some other developer may found arguable. But they proven themselves in multiple years of experience and we like to stick to them. Our credo is minimalism. Whenever problem raise how implement this or that feature we always go minimal way.

ConKit dictionary

It is important to get clear with the terms we use in the framework. Every application built with ConKit consists of set of modules.

Module is logically encapsulated part of the application. Usually one module is one webpage. But module may also include sub-modules.

Physically module consists of two files model and template.

Model is the part of module which does business logic of this particular module, retrieves data from storage and other backstage operations. Therefore normal model file consists of only PHP code.

Template is the part of module which visualizes data dug by the model. Physically template looks like HTML file with PHP insertions. We use native PHP templating mechanism.

If module doesn't need any backstage operations before visualization, then model file can be omitted.

Default module is the module which will be called if no other specified. For instance when you call http://www.myapp.com then default module will be retrieved.

Pre-module and post-module. Normally every website consists of header and footer which are more or less persistent and not to be repeated in every page. ConKit provides such mechanism. Whenever you call some module via HTTP request framework automatically wrap it with pre-module and post-module.

Note that sometime it is necessary to do changes in header or footer regarding actual content of the page. Say <title>, <keywords>, etc. You are able to do it, see core::prepend().

Note also that you are free to send your custom headers at any place of your code. Doesn't matter was there data output already or not.

MVC

ConKit is MVC-complaint framework. From the explanation above you may see that we have model files as "M" component and templates as "V" component. You may say that we miss component "C". Implementation of MVC is not strictly defined and vary from developer to developer. Our experience shows that in most cases "C" component carries routine duplicate information. It can be automatized without big loss. Therefore we embedded it into the framework core code.

Typical ConKit driven application directory

..
[conkit]      -- folder with FW codebase
index.php
header.tpl    -- pre-module template
footer.tpl    -- post-module template
home.tpl      -- default module template
home.php      -- default module model
another.tpl   -- another module template
another.php   -- another module model

Another option:

..
[conkit]              -- folder with FW codebase
[httpfiles]           -- web accessed directory
    index.php
    [models]          -- all models in one place
        home.php      -- default module template
        another.php   -- another module model
    [templates]       -- all templates in place
        header.php    -- pre-module template
        footer.php    -- post-module template    
        home.php      -- default module model
        another.php   -- another module template

Model and template files naming flexibly configurable. By default they considered in the same directory as index.php and named mymodule.mod.php and mymodule.tpl.php.

See also working samples included in the code package.

Technical implementation

Engine consists from the set of library functions which wrapped in few classes. There is no god object created during run. All methods of the engine classes are static. Complete list of the engine classes:

• core
• cms
• debug
• sql