Hi together!
As you've already noticed one of the improvements what was implemented in
upcoming eShop version was Bootstrap Process (BP) refactoring. It was mentioned
shortly, but I would like to reveal some more details about this change. I hope
this is an interesting and important information to you as OXID eShop partner
developer.
Bootstrap process is an initial script which includes, defines and initializes
all methods required for eShop framework to function correctly. The problem
what we wanted to solve was fuzzy and bloated existing BP. In earlier eShop
versions framework start time was not acceptable. There were incomaptibilities
among different entry points and due to BP limitations some fucntionality was
not possible to override with our module system. Additionally there were some
circular references which were not nice at all. In short this part needed
refactoring and we took some time and refactored the process completely.
This is what was improved:
BP defined exactly
OXID eShop execution is split into two clear parts: bootstrap process part and
the rest of the framework. All BP is isolated to new bootstrap.php file. It
makes it very trivial to include this file and after it is included into your
script, you have everything what is needed for framework initialisation.
As an example take a look to existing index.php file. Now it was reduxed to 2
simple lines of code:
require_once dirname(__FILE__) . "/bootstrap.php";
Oxid::run();
These 2 lines are enought to fire up the framework and start (and complete) the
shop execution.
Hint: you can also include bootstrap.php to any entry point for your project. I
kind of like it, do you? :)
BP is lightweight and fast
The main task of bootstrap.php is to read main config.inc.php, to init DB
connection (but not to make an actual connection yet) and to define the
__autoload().
The rest of init process what is needed in most cases (actuall DB connect,
module system init, config variable lodaing from DB, session init) are done on
demand (on the first related function call). This way the actual BP is very
fast. On my machine a script having only bootstrap.php takes 2% (15ms) of full
start page execution time.
Singeltons are replaced by Registry
Previously in order to get the instance of certain classes we were using
Singleton design patter. Example:
oxConfig::getInstance().
There is criticism of the use of the Singleton pattern, as some consider it an
anti-pattern. For some time we were considering what would be the best option
to replace Singeltons and decided to use Registry design pattern. An example
bellow shows how to get the single instance of utility classes using the
Registry:
oxRegistry::get("oxUtils");
The same applies to oxConfig and oxSession classes, you can get the instance
using oxregistry::get() method, or better, you can use already prepared
shortcut methods oxRegistry::getConfig() and oxRegistry::getSEssion():
$blShowArticles = oxRegistry::getConfig()->getConfigParam('blShowSomething');
$oSession = oxRegistry::getSession();
For more details see oxRegistry class implementation.
oxConfig and oxSession are overrideable by modules
Yes, they are! To be sure I've just checked again. This kind of module class is
a valid module for oxSession class:
class mySession extends mySession_parent
{
public function start()
{
echo "SESSION STARTED";
return parent::start();
}
}
Same with oxConfig. Stupid example, but it works:
class myConfig extends myConfig_parent
{
public function getConfigParam( $sParamName )
{
echo "$sParamName.<br>";
return parent::getConfigParam( $sParamName );
}
}
That's basically it, hope you like it. Please, treat this information as a
preview info, the changes are undergoing our QA process, so although unlikely,
minor changes are still possible.
Regards
Tomas Liubinas
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
