Joomla主进程分析纪要

Joomla的框架有许多可借鉴的编程思路，为自己更好的理解它，对主进程（index.php）的处理过程进行分析。（也是需要什么分析什么，因此，会一步一步完善这篇纪要）

（index.php)

<?php

// Set flag that this is a parent file

define( '_JEXEC', 1 );//定义执行中的参数

define('JPATH_BASE', dirname(__FILE__) );//定义系统的基本路径，__FILE__应该是PHP的全局参数（ TBD）

define( 'DS', DIRECTORY_SEPARATOR );//定义系统分割符，DIRECTORY_SEPARATOR是怎么来的，我还没有深入研究过（ TBD）

require_once ( JPATH_BASE .DS.'includes'.DS.'defines.php' );//在这里定义了Joomla运行中的很多常量，比如JPATH_ADMINISTRATOR什么的

require_once ( JPATH_BASE .DS.'includes'.DS.'framework.php' );// 这是执行主程序之前的相关设置，包括判断是否要进行安装，载入配置文件configuration.php，导入基础库文件（详见另文）

JDEBUG ? $_PROFILER->mark( 'afterLoad' ) : null;// 当设置进行Debug时，执行（另分析）

$mainframe =& JFactory::getApplication('site' );//创建一个JSite的实例

// set the language

$mainframe->initialise();// 调用JSite的函数，设置系统的默认语言

JPluginHelper::importPlugin('system');// 导入系统的插件

// trigger the onAfterInitialise events

JDEBUG ? $_PROFILER->mark('afterInitialise') : null;// TBD

$mainframe->triggerEvent('onAfterInitialise');// 触发了一个事件，具体实现需要用户自定义相关的处理函数，实际上，这就是Joomla插件的功能，通过插件来响应各种事件。

$mainframe->route();//这里对程序执行哪个组件进行了判断和设置。如果没有设置option（即要求执行的组件），系统会去找菜单的默认菜单项，调用这个菜单项执行。比如http://www.foo.com或 www.foo.com/index.php都会触发去找这个默认菜单项，假设默认菜单项定义的组件是com_content，则option这个时候会被设置为com_content，以供下面调用

 

//这里的route函数调用的JSite重载以后的函数，仔细研究这个函数，会发现根据前面生成的不同类型应用（Administrator，Site，Installation），系统会选择不同的JRouter类别

 

//菜单项激活和Itemid的应用问题

在生成的菜单项的链接中，有一个Itemid，实际上是菜单项的数据表ID，这个值的作用之一，是设置当前被激活的菜单项，以便后续使用（比如生成breadcrumbs时，能够确定当前的菜单项）

记录过程是在（$mainframe->route()）时发生的，Joomla在这里主要是对提交处理的uri进行分析，分析过程中记录Itemid为活动的菜单项。

// authorization

$Itemid = JRequest::getInt( 'Itemid');// TBD， 从提交的URL中得到菜单项的ID号

$mainframe->authorize($Itemid);// TBD，这里是通过一个JUser的“aid”变量进行验证，但这个变量是如何被赋值，在哪里被赋值，不知道？

// trigger the onAfterRoute events

JDEBUG ? $_PROFILER->mark('afterRoute') : null;// TBD

$mainframe->triggerEvent('onAfterRoute');// 事件处理，由插件响应

$option = JRequest::getCmd('option');//获得要求执行的组件，如果客户端没有提供，则由前面的route函数提供一个默认值

$mainframe->dispatch($option);//调用该组件，在这里输出的HTML文件被赋值， 注意：component的执行和渲染是在这里执行，因此后续的模版载入已经不能影响component的执行效果

// trigger the onAfterDispatch events

JDEBUG ? $_PROFILER->mark('afterDispatch') : null;// TBD

$mainframe->triggerEvent('onAfterDispatch');// 事件处理，由插件响应

 

$mainframe->render();//渲染框架，实际上是显示，这个时候，将调用模板(template)，如果需要根据不同的组件显示不同的模板，那么在模板中的index.php中进行设置即可

 

这是一个比较复杂的部分，系统分成两个部分：Header和Body，Joomla的输出实际上是调用JResponse的SetHeader和SetBody函数，其中setheader基本上是在JApplication基类中实现，而后者却需要具体的JSite来完成。

 

在SetBody部分，根据输出的内容不同，会调用不同的JDocument，一般情况下是JDocumentHTML，通过这个类的render函数输出需要显示的内容$data，然后SetBody($body)。

 

特别的，JDocumentHTML的render又调用其_parseTemplate函数，将模版文件中的jdoc:include全部替换为相应的module或component（component的渲染结果在前面的dispatch过程中已经被载入到DocomentHTML中），并执行各自的render函数，输出真实的模块（很有趣的部分）

 

//这里还没有真输出，通过JResponse::setBody($data)把内容放到全局变量中

// trigger the onAfterRender events

JDEBUG ? $_PROFILER->mark('afterRender') : null;// TBD

$mainframe->triggerEvent('onAfterRender');// 事件处理，由插件响应

 

echo JResponse::toString($mainframe->getCfg('gzip' ));//输出前面准备这么久的结果，真是不容易啊，实际上toString做了以下几件事：

//首先通过$data = JResponse::getBody();得到应该输出的页面

//然后判断是否要压缩，如果要压缩，则压缩

//第三步，处理缓存什么的TBD

//第四步，输出Head，JResponse::sendHeaders();

//最后，返回一个字符串，让主程序输出(echo)