I need to optionally include some modules in my ZF2 app. The modules are entirely independent with any loaded modules.
In application.config.php, in the config array I can just include the main modules, and then, at the end, based on some conditions, to add the optional module. Like this:
$config = array(
'modules' => array(
'Application',
),
...
);
if (condition) {
$config['modules'][] = 'OptionalModule';
}
return $config;
Though this works and fixes the problem, I was wondering if there is another way of doing this.
Is it a good approach for this use case? Would there be a nicer way to accomplish this?
Thanks!
I usually do this by using any of the below two methods:
Conditionally load module with local application config
application.config.php:
<?php
use Zend\Stdlib\ArrayUtils;
$config = [
// You config
];
$local = __DIR__ . '/application.config.local.php';
if (is_readable($local)) {
$config = ArrayUtils::merge($config, require($local));
}
return $config;
application.config.local.php:
<?php
return [
// Your config
];
This enables you to have a base application config and load an additional config per deployment. So no if $condition, this is determined by your deployment process, which is most times easier to manage.
Note this also works for deployment configs: application.config.development.php vs application.config.production.php. This is just whatever you like, to suit your needs.
Conditionally execute code in module config
In your Module.php
<?php
namespace MyModule;
use Zend\Mvc\MvcEvent;
class Module
{
public function onBootstrap(MvcEvent $e)
{
$app = $e->getApplication();
$sm = $app->getServiceManager();
$config = $sm->get('Config');
if ($config['mymodule']['enabled'] === true) {
// condition
}
}
}
Then you can have your module.config.php in your own module folder:
<?php
return [
'mymodule' => [
'enabled' => true,
],
];
But if youn need to disable this in a certain environment, you add this to your config/autoload/local.php:
<?php
return [
'mymodule' => [
'enabled' => false,
],
];
Related
I have a Yii 1.x component loaded in the configuration file like so
$config['components']['simplesamlphp'] = array(
'class' => 'application.components.yii-simplesamlphp.components.Simplesamlphp',
'autoloadPath' => SAML_DIR.'/test2/lib/_autoload.php',
'authSource' => 'default-sp',
);
I need to make the autoloadPath property dynamic based on who the user is in the controller. Is this possible? And if so how do I overwrite it?
Probably the best way is to extend Simplesamlphp and configure property in init():
class MySimplesamlphp extends Simplesamlphp {
public $adminAutoloadPath;
public $nonAdminAutoloadPath;
public function init() {
if (Yii::app()->user->isAdmin()) {
$this->autoloadPath = $this->adminAutoloadPath;
} else {
$this->autoloadPath = $this->nonAdminAutoloadPath;
}
parent::init();
}
}
And use new component in config:
$config['components']['simplesamlphp'] = array(
'class' => 'MySimplesamlphp',
'adminAutoloadPath' => SAML_DIR.'/test2-admin/lib/_autoload.php',
'nonAdminAutoloadPath' => SAML_DIR.'/test2/lib/_autoload.php',
'authSource' => 'default-sp',
);
I figured it out overriding yii components is fairly easy even if you dont initialize it in the config.
$component = array(
'class' => 'application.components.yii-simplesamlphp.components.Simplesamlphp',
'autoloadPath' => SAML_DIR.'/'.$tenant_path.'/lib/_autoload.php',
'authSource' => 'default-sp',
); //where $tenant_path is the directory of the component i need based on the tenant
Yii::app()->setComponent('simplesamlphp',$component);
then use the component in your controller like so
Yii::app()->simplesamlphp;
Note that you will only have access to the component within your controller method so all i did was move the that code to its own class and call it when i needed to create a new instance of the component
I'm interested in having a unified backend environment for multiple users and having multiple frontend environments for users. All should run from a single application instance, which will be the equivalent of the app folder. I've gone back and forth on several configurations but keep running into inconsistencies once I get deeper into the app. Imagine something like the enterprise WordPress app: users need a unique webroot for their account for accessing their templates and digital assets, but one application instance runs the backend environment for all users. This is proving tricky on Lithium.
Right now, I set a basic environment parameter in the /[user]/webroot/index.php file, like so:
<?php
$env = ['webroot' => __DIR__, 'id' => 'generic_account'];
require dirname(dirname(__DIR__)) . '/app/config/bootstrap.php';
use lithium\action\Dispatcher;
use lithium\action\Request;
echo Dispatcher::run(new Request(compact('env')));
?>
Then, in the Dispatcher, I have an extension class map the account:
Dispatcher::applyFilter('run', function($self, $params, $chain) use (&$i) {
Environment::set($params['request']);
//Map $env['id'] value to stored database connection
if (isset($params['request']->id)) {
Accounts::load($params['request']);
}
foreach (array_reverse(Libraries::get()) as $name => $config) {
if ($name === 'lithium') {
continue;
}
$file = $config['path'] . '/config/routes.php';
file_exists($file) ? call_user_func(function() use ($file) { include $file; }) : null;
}
return $chain->next($self, $params, $chain);
});
Finally, in the Accounts::load() method, I pull connection settings from a master database and set those as the default Connection configuration:
<?php
namespace app\extensions\core;
use app\models\Routes;
use lithium\net\http\Router;
class Accounts {
public static function load(&$request) {
if (!is_object($request)) {
return false;
}
$class = [
'accounts' => 'app\models\Accounts',
'plugins' => 'app\extensions\core\Plugins',
'prefs' => 'app\extensions\core\Preferences',
'connections' => 'lithium\data\Connections',
'inflector' => 'lithium\util\Inflector',
'exception' => 'lithium\net\http\RoutingException'
];
$class['accounts']::meta('connection', 'master');
$bind = $class['prefs']::read('bind_account');
$key = $bind == 'domain' || $bind == 'subdomain' ? 'HTTP_HOST' : 'id';
$find = $class['accounts'] . '::' . $class['inflector']::camelize('find_by_' . $bind, false);
$account = call_user_func($find, $request->env($key));
if ($account == null) {
throw new $class['exception']('Account `' . $request->env($key) . '` doesn\'t exist.');
}
$class['connections']::add('default', json_decode($account->database, true));
$request->activeAccount = $account;
$request->params['webroot'] = $request->env('webroot');
$plugins = $class['plugins']::load();
return true;
}
/**
* Allows users to store customized route definitions in `routes` table,
* hence the use of `app\models\Routes`.
*/
public static function routes() {
$routes = Routes::all();
foreach ($routes as $route) {
Router::connect($route->match, [
'controller' => 'pages',
'action' => 'view',
'template' => $route->template,
'layout' => $route->layout
]);
}
}
}
?>
All this seems to work well for routing URLs and allowing for multiple front-end webroots. Here's the trick: when creating a webroot for admin interfaces, it's turning into a convoluted mess for keeping the asset paths straight. I've used Media::assets() to try to overcome this, but I have a feeling there's a more elegant solution out there. I've struggled to find any other examples or documentation that specifically addresses this kind of setup concern.
It's pretty straightforward, you're almost there. All you really need is a unique webroot/ directory per user, in addition to the normal bootstrap include and request-dispatching, you can include any other user-specific configuration, and register the main application, like so:
Libraries::add('yourApp', [
'path' => '/path/to/codebase',
'webroot' => __DIR__
]);
This gives you the centralized codebase, but also allows for a custom webroot per user.
I have two platforms on lithium with a similar setup. I wrote a plugin called li3_saas to facilitate it which I think I still need to put up on github. But it does some similar things with loading from a master database and setting the default database to be user specific.
I would recommend an entirely different app for a global admin interface that can load your main app using Libraries::add(), possibly with the 'bootstrap => false option to skip loading the bootstrap.
I accomplish some things - like reusing css or js - with symlinks on the file system.
I do use Media::assets() to let my admin interface know where uploaded files exist. I create a custom key in there called 'upload' and use that when creating assets paths and urls.
I could elaborate on that. Can you give a more specific use case that you are trying to solve?
How I can get access to my module config from the controller?
I am really surprised at how obscure this is, because I had exactly the same problem and could not find a definitive answer. One would think the ZF2 documentation would say something about this. Anyhow, using trial and error, I came across this extremely simple answer:
Inside controller functions:
$config = $this->getServiceLocator()->get('Config');
Inside Module class functions (the Module.php file):
$config = $e->getApplication()->getServiceManager()->get('Config');
whereas $e is an instance of Zend\Mvc\MvcEvent
In general, the config is accessible from anywhere you have access to the global service manager since the config array is registered as a service named Config. (Note the uppercase C.)
This returns an array of the union of application.config.php (global and local) and your module.config.php. You can then access the array elements as you need to.
Even though the OP is quite old now, I hope this saves someone the hour or more it took me to get to this answer.
What exactly do you want to do in your controller with the module configuration? Is it something that can't be done by having the DI container inject a fully configured object into your controller instead?
For example, Rob Allen's Getting Started with Zend Framework 2 gives this example of injecting a configured Zend\Db\Table instance into a controller:
return array(
'di' => array(
'instance' => array(
'alias' => array(
'album' => 'Album\Controller\AlbumController',
),
'Album\Controller\AlbumController' => array(
'parameters' => array(
'albumTable' => 'Album\Model\AlbumTable',
),
),
'Album\Model\AlbumTable' => array(
'parameters' => array(
'config' => 'Zend\Db\Adapter\Mysqli',
)),
'Zend\Db\Adapter\Mysqli' => array(
'parameters' => array(
'config' => array(
'host' => 'localhost',
'username' => 'rob',
'password' => '123456',
'dbname' => 'zf2tutorial',
),
),
),
...
If you need to do additional initialization after the application has been fully bootstrapped, you could attach an init method to the bootstrap event, in your Module class. A blog post by Matthew Weier O'Phinney gives this example:
use Zend\EventManager\StaticEventManager,
Zend\Module\Manager as ModuleManager
class Module
{
public function init(ModuleManager $manager)
{
$events = StaticEventManager::getInstance();
$events->attach('bootstrap', 'bootstrap', array($this, 'doMoarInit'));
}
public function doMoarInit($e)
{
$application = $e->getParam('application');
$modules = $e->getParam('modules');
$locator = $application->getLocator();
$router = $application->getRouter();
$config = $modules->getMergedConfig();
// do something with the above!
}
}
Would either of these approaches do the trick?
for Beta5, you can add function like this in Module.php
public function init(ModuleManager $moduleManager)
{
$sharedEvents = $moduleManager->getEventManager()->getSharedManager();
$sharedEvents->attach(__NAMESPACE__, 'dispatch', function($e) {
$config = $e->getApplication()->getConfiguration();
$controller = $e->getTarget();
$controller->config = $config;
});
}
in controller, you can get config :
print_r($this->config);
To read module-only config your module should just implement LocatorRegisteredInterface
Before:
namespace Application;
class Module
{
// ...
}
After:
namespace Application;
use Zend\ModuleManager\Feature\LocatorRegisteredInterface;
class Module implements LocatorRegisteredInterface
{
// ...
}
That implementation says LocatorRegistrationListener to save module intance in service locator as namespace\Module
Then anywhere you can get access to your module:
class IndexController extends AbstractActionController
{
public function indexAction()
{
/** #var \Application\Module $module */
$module = $this->getServiceLocator()->get('Application\Module');
$moduleOnlyConfig = $module->getConfig();
// ...
}
}
There is a pull request ready now which pulls the module class (so the modules/foo/Module.php Foo\Module class) from the DI container. This gives several advantages, but you are also able to grab that module instance another time if you have access to the Zend\Di\Locator.
If your action controller extends the Zend\Mvc\Controller\ActionController, then your controller is LocatorAware. Meaning, upon instantiation your controller is injected with the locator knowing about modules. So, you can pull the module class from the DIC in your controller. Now, when your module consumes a config file and stores this inside the module class instance, you can create a getter to access that config data from any class with a locator. You probably have already an accessor with your module Foo\Module::getConfig()
While ZF2 is heavily under development and perhaps this code will change later on, this feature is currently covered by this test, with this the most relevant part:
$sharedInstance = $locator->instanceManager()->getSharedInstance('ListenerTestModule\Module');
$this->assertInstanceOf('ListenerTestModule\Module', $sharedInstance);
So with $sharedInstance your module class, you can access the config from there. I expect a shorthand for this feature soon, but this can only be done after PR #786 has been merged in ZF2 master.
You need to implements ServiceLocatorAwareInterface from your model. And then you can set setServiceLocator() and getServiceLocator() which give you direct access to the service manager. Take a look at this code sample https://gist.github.com/ppeiris/7308289
I created the module with controller plugin and view helper for reading a config in controllers and views. GitHub link __ Composer link
Install it via composer
composer require tasmaniski/zf2-config-helper
Register new module "ConfigHelper" in your config/application.config.php file
'modules' => array(
'...',
'ConfigHelper'
),
Use it in controller and view files
echo $this->configHelp('key_from_config'); // read specific key from config
$config = $this->configHelp(); // return config object Zend\Config\Config
echo $config->key_from_config;
you can also access any config value anywhere by this hack/tricks
$configReader = new ConfigReader();
$configData = $configReader->fromFile('./config.ini');
$config = new Config($configData, true);
I have a questiom regarding the Zend Framework 2:
I have
library/System and library/Zend. the system is my custom library, which I want to configure de aplication (routes, modules, etc., and redirect user to correct module, controller and/or action).
I don't want to do this inside each application/modules/ModuleName/Module.php file. So, my library/System can do everything related to application configuration.
As said in the comments above: register to the bootstrap-event and add new routes there:
<?php
namespace Application;
use Zend\Module\Manager,
Zend\EventManager\StaticEventManager;
class Module
{
public function init(Manager $moduleManager)
{
$events = StaticEventManager::getInstance();
$events->attach('bootstrap', 'bootstrap', array($this, 'initCustom'), 100);
}
public function initCustom($e)
{
$app = $e->getParam('application');
$r = \Zend\Mvc\Router\Http\Segment::factory(array(
'route' => '/test',
'defaults' => array(
'controller' => 'test'
)
)
);
$app->getRouter()->addRoute('test',$r);
}
}
$app = $e->getParam('application'); does return an instance of Zend\Mvc\Application. Have a look there to see which additional parts you can get there. The bootstrap event is fired before the actual dispatching does happen.
Note that the ZendFramework 1 routes are not always compatible to the ZendFramework 2 ones.
Update to comments
public function initCustom($e)
{
$app = $e->getParam('application');
// Init a new router object and add your own routes only
$app->setRouter($newRouter);
}
Update to new question
<?php
namespace Application;
use Zend\Module\Manager,
Zend\EventManager\StaticEventManager;
class Module
{
public function init(Manager $moduleManager)
{
$events = StaticEventManager::getInstance();
$events->attach('bootstrap', 'bootstrap', array($this, 'initCustom'), 100);
}
public function initCustom($e)
{
$zendApplication = $e->getParam('application');
$customApplication = new System\Application();
$customApplication->initRoutes($zendApplication->getRouter());
// ... other init stuff of your custom application
}
}
This only happens in one zf2 module (named Application which can be the only one as well). This doesn't fit your needs? You could:
extend a custom module autoloader
extend Zend\Mvc\Application for your own logic
make your code zf2-compatible
We're using ZendFramework at my workplace for our webapps. It's ok, but it lacks some of the best modern practices (like dependency injection and inversion of control, aop, etc).
For a couple of months, I've been (on my own) using Ding framework as a container for DI and AOP as a test drive. I really like it, so I'd like to bring it into our projects.
But how? So there's the question: how to properly integrate Ding in Zend Framework applications? considering ZF controllers cant be beans (as they are instantiated right from the dispatcher), how to propertly inject all dependencies in them?
P.s: Not using Zend Framework is not an option (at least in the middle term).
P.P.S: Anyone care to add "ding" as a new tag?
I'm glad Ding is helping you.
I contributed on this project and also needed to integrate with a Zend Framework application. I used Zend's application resources and plugin system to achieve this.
An application resource (you can reuse among projects)
<?php
class Application_Resource_Ding extends Zend_Application_Resource_ResourceAbstract
{
protected $_options = array(
'factory' => array(
'bdef' => array(
'xml' => array(
'filename' => array('beans.xml')
),
),
),
'cache' => array(
'proxy' => array('impl' => 'dummy'),
'bdef' => array('impl' => 'dummy'),
'beans' => array('impl' => 'dummy')
)
);
public function init()
{
// set default config dir before mergin options (cant be set statically)
$this->_options['factory']['bdef']['xml']['directories'] = array(APPLICATION_PATH .'/configs');
$options = $this->getOptions();
// parse factory properties (if set)
if (isset($options['factory']['properties'])) {
$options['factory']['properties'] = parse_ini_file(
$options['factory']['properties']
);
}
// change log4php_properties for log4php.properties (if exists)
if (isset($options['log4php_properties'])) {
$options['log4php.properties'] = $options['log4php_properties'];
unset($options['log4php_properties']);
}
$properties = array(
'ding' => $options
);
return Ding\Container\Impl\ContainerImpl::getInstance($properties);
}
}
An action helper to use inside the controllers:
<?php
class Application_Action_Helper_Ding extends Zend_Controller_Action_Helper_Abstract
{
protected $ding = null;
public function init()
{
// just once...
if (null !== $this->ding) {
return;
}
// get ding bootstrapped resource
$bootstrap = $this->getActionController()->getInvokeArg('bootstrap');
$ding = $bootstrap->getResource('ding');
if (!$ding) {
throw new Zend_Controller_Action_Exception(
'Ding resource not bootstrapped'
);
}
$this->ding = $ding;
}
public function getBean($bean)
{
return $this->ding->getBean($bean);
}
public function direct($bean)
{
return $this->getBean($bean);
}
}
In your application.ini you should add something like this (plus any extra configuration you need)
resources.frontController.actionHelperPaths.Application_Action_Helper = "Application/Action/Helper"
resources.ding.factory.properties = APPLICATION_PATH "/configs/ding.properties"
resources.ding.log4php_properties = APPLICATION_PATH "/configs/log4php.properties"
And then in your controllers, to request a bean:
$service = $this->_helper->ding('someService');
Hope this helps!