My answer to "How the Request will be passed to index page"

This is my answer to a Question on Support site for LampCMS project

the value of 'a' resolved to name of controller - a class in the Lampcms/Controllers directory.
For example the a=unanswered resolved to Lampcms/Controllers/Unanswered.php

If controller does not exist for the action (this should never happen) then there will be an error.
Every controller class extends Lampcms/WebPage.php

The job of controller is to implement own main() method and setup the values in the this->aPageVars array. This array is then passed to tplMain template and the page is rendered. WebPage class sets up some vars then calls the main().
Controllers all have their own version of main() - that's where controller does their main processing and controller usually sets up the values of ['body'] which is the main area of page and often the value of side navigation blocks, the page title.

After the main() is run, the controller adds some extra values to aPageVars and the in index.php there is this line:
echo new $class($Registry);

This calls the __toString() method in WebPage which basically passes the aPageVars array to the tplMail::parse() and that gets back the html of the web page. The page is echoed to the browser.

There is also an Event Dispatcher involved. The Controller and WebPage class (which is base for every controller) does post some events to event dispatcher, for example 'onPageView', 'onBeforeNewQuestion', 'onNewQuestion', etc.

This allows to write and add custom modules that extends Lampcms/Event/Observer and then these modules are registered as observers and receive all events. Any one of the observers usually ignores most of the events and acts only when specific event occurs. There are several modules that exist, so you can see how they are written. For example Email notifications is a module. Just look in Modules and Modules/Observers directory for some examples. Every Observer since it extends Lampcms\Event\Observer has access to Registry object, meaing it can access the Mongo, Request, and some other important objects from it. A custom observer module just has to implement own main() method and inside that main() method do it's logic. Usually an observer module will first examing the name of the $this->eventName and see if it's the event it's interested in.

Last thing is fastcgi_finish_request() is run and it often runs some extra functions that have been setup usually in custom modules. These functions all run after the page has been served to used, so user experience does not suffer by running some functions that can be run after the page is returned. Such functions may include adding the new question to search index. finding similar questions, posting the new question/answer to twitter, facebook, tumblr, linkedin, emailing users who may be subscribed to that particular tag, updating the 'whos online' collection, which resolved ip to geo location. All these extra steps run after the page is returned and connection to browser is closed. The end-result is similar to offloading the extra work to another thread in Java. Of cause in Java you can create more than one thread and run each task separately, but that's a different story. The user experience is still the same - page is served as fast as possible and extra processing is done afterwards if possible.