I am new to this zend2, previously I worked with CAKEPHP & codeigniter. I want to write some constant values in a particular file & be able to access them any where in the project.
In cakephp it is like Configure::write('environment','dev'); we write this in a file in Config folder which will be at app/Config/file name
and we can access this like $env = Configure::read('environment'); any where..
Can we do in the same way in zend framework 2, like defining the constants in a file & can access them anywhere..?
Please give an example how to define & read it with the path of the file
No is the short answer. Cake, ZF1, CodeIgniter all made use of a design pattern, now widely discouraged, called the the Registry Pattern (which is really just a Singleton).
The very fact that this class is globally accessible, is one of the reasons why its use is not advised.
ZF2 has a completely different architecture and offers a flexible approach by merging configuration based on environment variables. An when it comes to 'using' the configuration, you should be injecting it into your services using the service manager and a service factory.
First define variable in config
Like:-
accountUser.admin = "admin"
Then initialize object like(in controller or model):-
$config = new Zend_Config_Ini(APPLICATION_PATH . '/configs/config.ini', APPLICATION_ENV);
// APPLICATION_PATH is path to project
// APPLICATION_ENV will be your environment
Then use it like:-
$admin = $config->accountUser->admin;
Related
I've been reading on many sites even here that in order to improve performance of Zend Framework applications is not to use the Zend_Application in bootstrap, but haven't been able to find a site that has this demonstrated.
Do you guys know of a place that has this method described and might provide me with some code samples?
Thanks
I just threw this together:
https://gist.github.com/2822456
Reproduced below for completion. Not tested, just some ideas for how I think it generally (!) might work. Now that i have walked through it a bit, I have a greater appreciation for Zend_Application, its bootstrap classes, and its configurable/reusable application resources. ;-)
// Do your PHP settings like timezone, error reporting
// ..
// Define path to application directory
defined('APPLICATION_PATH')
|| define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/_zf/application'));
// Define application environment
defined('APPLICATION_ENV')
|| define('APPLICATION_ENV', (getenv('APPLICATION_ENV') ? getenv('APPLICATION_ENV') : 'production'));
// Ensure library/ is on include_path
set_include_path(implode(PATH_SEPARATOR, array(
realpath(APPLICATION_PATH . '/../library'),
get_include_path(),
)));
// Get autoloading in place
require_once 'Zend/Loader/Autoloader.php';
$autoloader = Zend_Loader_Autoloader::getInstance();
// Any additional configs to autoloader, like custom autoloaders
// Read config
$config = new Zend_Config_Ini(APPLICATION_PATH . '/configs/application.ini', APPLICATION_ENV);
// bootstrap resources manually:
// * create db adapter
// * create resource autoloaders with the mappings you need
// * etc
// Get the singleton front controller
$front = Zend_Controller_Front::getInstance();
// Set controller directory
$front->setControllerDirectory(APPLICATION_PATH . '/controllers');
// Or set module directory
$front->setModuleDirectory(APPLICATION_PATH . '/modules');
// Other front config, like throw exceptions, etc.
// ...
//
// Create a router
$router = new Zend_Controller_Router_Rewrite();
// Add routes to the router
$router->addRoute('myRoute', new Zend_Controller_Router_Route(array(
// your routing params
)));
// More routes...
// Alternatively, the routes can all be in an xml or ini file and you can add
// them all at once.
// Tell front to use our configured router
$front->setRouter($router);
// Add an plugins to your $front
$front->registerPlugin(new My_Plugin());
// other plugins...
// Dispatch the request
$front->dispatch();
There might be some View/ViewRenderer stuff to do, as well. But as noted in other places, the ViewRenderer incurs a non-trivial performance hit. If performance is the issue, then you'll want to disable the ViewRenderer and make your action controllers call their own rendering using $this->view->render('my/view-script.phtml')
When you call $front->dispatch(), the $request and $response objects will be created automatically. If you want to do something specific to them at bootstrap - like setting the charset in Content-Type header of the response - then you can create your request/response object yourself, do what you want to it, and then attach it to the front with $front->setResponse($response); Same for the request object.
Although I see that my example uses Zend_Loader_Autoloader and Zend_config_Ini which Padraic notes incur performance hits. The next step would be to address those by using arrays for config, stripping require_once calls from the framework, registering a different autoloader, etc, an exercise left for the reader... ;-)
Hi I disagree somewhat with the not using Zend_Application in bootstrap and no I have yet to see a concrete example of this technique.
Personally I don't see the benefit in not using Zend_app for bootstrapping your application, assuming a) Your doing things 'the Zend way' and b) your project is either big enough or just simply warrants using the Zend framework (or any for that matter).
While Zend_App is great for creating consistent complex bootstraps
within a standardised structure, it doesn’t come without a significant
performance hit to baseline performance. A more direct bootstrap
(typical of ZF until Zend_App arrived) is far faster and can also be
done without configuration files.
Taken from Pádraic Brady link.
Well to me the above does not make sense, he basically just said Zend_App is great for complex bootstraps, but adds a performance hit. But isn't that the premise for ANY framework / framework component? I know Padraic is a very clever guy and I'm sure he has his reasoning, but I too would love to see examples / evidence of this suggestion.
Perhaps in answer to your question, you could benchmark a basic app using the latest Zend framework and then use Zend framework from < 1.10 using the old non Zend_App way, but I would say although clearly not perfect Zend_App is clearly faster to get most app's up and running, so whether this is worth 'the performance hit' is I guess up to the developer(s).
Here is a link which somewhat goes into what you may be after but makes reference to a modular approach (still interesting, none the less):
http://www.osebboy.com/blog/zend-framework-modules/
I want to know a clean way of defining Application Constants in Codeigniter. I don't want to change any native file of codeigniter. Hence I don't want to define it in application/config/constants.php as when I need to migrate to newer version of code-igniter I will not be able to copy the native files of codeigniter directly.
I created a file application/config/my_constants.php and defined my constants there. 'define('APP_VERSION', '1.0.0');'
I loaded it using $this->load->config('my_constants');
But I am getting a error
Your application/config/dv_constants.php file does not appear to contain a valid configuration array.
Please suggest me a clean way of defining application level constants in code-igniter.
Not using application/config/constants.php is nonsense! That is the only place you should be putting your constants. Don't change the files in system if you are worried about upgrading.
just a complete answer. (None of the answers show how to use the constants that were declared)
The process is simple:
Defining a constant. Open config/constants.php and add the following line:
define('SITE_CREATOR', 'John Doe')
use this constant in another file using:
$myVar = 'This site was created by '.SITE_CREATOR.' Check out my GitHub Profile'
Instead of using define(), your my_constants.php file should look something like this:
$config['app_version'] = '1.0.0';
Be careful with naming the array key though, you don't want to conflict with anything.
If you need to use define(), I would suggest doing it in the main index.php file, though you will still need to use APP_VERSION to get the value.
config file (system/application/config/config.php) to set configuration related variables.
Or use
constant file (system/application/config/constants.php) to store site preference constants.
=======================
DEFINE WHAT YOU WANT
=======================
$config['index_page'] = 'home';
$config['BASEPATH'] = 'PATH TO YOUR HOST';
Please refer this:
http://ellislab.com/forums/viewthread/56981/
Define variable in to constants & add value on array
$ORDER_STATUS = array('0'=>'In Progress','1'=>'On Hold','2'
=>'Awaiting Review','3'=>'Completed','4'
=>'Refund Requested','5'=>'Refunded');
You can accomplish your goal by adding constants to your own config file, such as my_config.php.
You would save this file in the application/config folder, like this:
application/config/my_config.php.
It is very common to have a separate config file for each application you write, so this would be easy to maintain and be understood by other CI programmers.
You can instruct CI to autoload this file or you can load it manually, as needed. See the CI manual on "Config class".
Let me suggest that you use composer.json to autoload your own Constants.php file, like this:
We have used Zend_Log, which is configured in application.ini differently for different circumstances. We initialize it/get it in the bootstrap and store it in the registry:
$r = $this->getPluginResource('log');
$logger = $r->getLog();
But we've subclassed Zend_Log (say, Our_Log) to add customized features, and want to get it the same way. So then we have to make a new Resource Plugin. That seems quite easy - just copy Application/Resource/Log.php, rename the file to Ourlog.php, rename the class to class Zend_Application_Resource_Ourlog. For now, let's not worry about "Our_Log", the class -- just use the new Resource Plugin to get a Zend_Log, to reduce the variables.
So then, our new code in the bootstrap is:
$r = $this->getPluginResource('ourlog');
$logger = $r->getLog();
but of course this doesn't work, error applying method to non-object "r". According to the documentation,
"As long as you register the prefix path for this resource plugin, you
can then use it in your application."
but how do you register a prefix path? That would have been helpful. But that shouldn't matter, I used the same prefix path as the default, and I know the file is being read because I "require" it.
Anyway, any guidance on what simple step I'm missing would be greatly appreciated.
Thanks for the pointers -- so close, so close (I think). I thought I was getting it...
Okay, so I renamed the class Xyz_Resource_Xyzlog, I put it in library/Xyz/Resource/Xyzlog.php
Then, because I don't love ini files, in the bootstrap I put:
$loader=$this->getPluginLoader();
$loader->addPrefixPath('Xyz_Resource','Xyz/Resource/');
$r = $this->getPluginResource('xyzlog');
if (!is_object($r)) die ('Not an object!!');
Sudden Death. So, okay, do the ini:
pluginPaths.Xyz_Resource='Xyz/Resource/'
The same. No help. I believed that the basepaths of the plugin paths would include the PHP "include" paths. Am I mistaken in that? Any other ideas? I'll happily write up what finally works for me to help some other poor soul in this circumstance. Something to do with Name Spaces, maybe?
Plugin classes are resolved using the plugin loader, which works slightly differently to the autoloader; so just requiring the class in doesn't help you here. Instead, add this to your application.ini:
pluginPaths.Application_Resource = "Application/Resource"
you should then be able to use the class as normal. Since your path above will be checked before the default Zend one, you can also name your class 'Log' and still extend the Logger resource to override the standard functionality.
i am new to Zend Framework and i want to know how to get the application environment in my controller.
I read in a forum to use: echo getenv('APPLICATION_ENV'); but it does not work.
Since APPLICATION_ENV is a constant, you can access it simply with:
echo APPLICATION_ENV;
But the question is why would you need it in your controller.
There is another way to get the environment name. It's a little more OO-friendly for those of us who prefer to avoid globally defined constants, but I'm not quite sure how to get at it:
$myEnvName = $zendApplicationInstance->getEnvironment();
The question here is how to get the reference to $myEnvName -- suggestions welcome.
I am trying to decide on the best way to store my applications configuration settings. There are so many options.
The majority of applications I have seen have used a simple require and a PHP file that contains variables. There seem to be far more advanced techniques out there.
What have you used?
What is most efficient?
What is most secure?
We use a file called Local.php which is excluded from the SCM system. It contains several constants or global variables. For example:
// Local.php
class Setting
{
const URL = 'http://www.foo.com';
const DB_User = 'websmith';
}
And it can be referred to anywhere simply by:
Setting::URL
If you need the settings to be writable at runtime, I suggest you use public static variables instead.
The best thing you can do is the simplest thing that could possibly work (php variables) and wrap it up in a class. That way you can change the implementation later without changing any client code. Create an interface that the configuration class implements and make the client code use the interface methods. If you later decide to store configuration in a database or JSON or whatever, you can simply swap out the existing implementation with a new one. Make sure your configuration class is testable and write unit tests.
Try to use php-arrays config files using technique described here: http://www.dasprids.de/blog/2009/05/08/writing-powerful-and-easy-config-files-with-php-arrays
This method allows you to write app configuration in this way:
app.config.php
<?php
return array(
'appname' => 'My Application Name',
'database' => array(
'type' => 'mysql',
'host' => 'localhost',
'user' => 'root',
'pass' => 'none',
'db' => 'mydb',
),
);
This method is secure, cache-able by opcode cachers (APC, XCACHE).
How about:
; <?php die('Direct access not allowed ;') ?>
; The above is for security, do not remove
[database]
name = testing
host = localhost
user = root
pass =
[soap]
enableCache = 1
cacheTtl = 30
Save as config.php (or something like that, must have php extention), and then just load it with:
parse_ini_file('config.php', true);
And you could use
array_merge_recursive(parse_ini_file('config-default.php', true), parse_ini_file('config.php', true))
to merge a default config file with a more specific config file.
The point here is that you can use the very readable ini format, but still be able to have your config file in a public directory.
When you open the file with your browser, php will parse it first and give you the result, which will just be "; Direct access not allowed ;". When you parse the file directly as an ini file, the php die statement will be commented out according to the ini syntax (;) so it will not have any effect then.
I find Zend_Config to be a good solution. You can load the configuration from a simple array, from an INI style file, or from an XML document. Whichever you choose, the configuration object is the same, so you can switch storage formats freely. Zend_Config objects can also be merged, depending on your application this may be useful (a server config, then a per site/installation config).
As with most (or all) things in the Zend Framework, you can easily use Zend_Config by itself.
Considering efficiency, I'd say the fastest method would be to use an array, since that requires less (in this case no) string parsing. However, a INI/XML format may be easier for some to maintain. Of course some caching would give you the best of both worlds.
Also, using INI files with Zend_Config allow you to define sections of configurations that inherit from each other. The most common use is a 'development' section that inherits from the 'production' section, then redefines the DB/debugging settings.
As for security, keeping the config file out of the web root is the first step. Making it read only and limiting access could make it more secure; however, depending on your hosting/server configuration you may be limited in what can be done there.
Just an example of how to implement a central XML/Xpath configuration.
class Config {
private static $_singleton;
private $xml;
static function getInstance() {
if(is_null (self::$_singleton) ) {
self::$_singleton = new self;
}
return self::$_singleton;
}
function open($xml_file) {
$this->xml = simplexml_load_file($xml_file);
return $this;
}
public function getConfig($path=null) {
if (!is_object($this->xml)) {
return false;
}
if (!$path) {
return $this->xml;
}
$xml = $this->xml->xpath($path);
if (is_array($xml)) {
if (count($xml) == 1) {
return (string)$xml[0];
}
if (count($xml) == 0) {
return false;
}
}
return $xml;
}
}
Example call
Config::getInstance()
->open('settings.xml')
->getConfig('/settings/module/section/item');
In my view good solution would be ini files.
I don't prefer config file using arrays/variables for storing settings; here is why:
What if a user accidently re-named your setting variable?
What if a variable with similar name is defined elsewhere too by the user?
Variables in config file may be overwritten some where deep in the script or even included files.
and possibly more problems....
I like to use ini file for setting of my php apps. Here is why:
It is section based
It is easier
You can set values by friendly names
You don't have to worry about variables being overwritten because there are no ones.
No conflict of variables of course.
It allows more flexibility in specifying the types of values.
Note: You need to use parse_ini_file function to read ini files.
It is best to do any core configuration in PHP itself, but if you are using a database and don't mind the extra overhead - you may find some flexibility in storing some settings in the database with a single extra query (assuming you organize it properly).
Either way, storing this data in JSON, INI, XL, etc is just another unneeded abstraction that is done way too much nowadays on the web. Your best bet is pure PHP, unless you like the flexibility of some settings being in the database.
The only reason I can think of to not use php vars as others are suggesting is if you need to switch between configurations in a controlled manner, so there data/behavior consistency during the switch. For example, if you're switching databases, then the system could write locked until the switch-over occurs (to prevent ghost-writes, but dirty reads are still possible).
If things like this are a concern, then you could write a special admin page in your app(pref local access only for security) that locks the system temporarily, then reads and deploys all your changes before unlocking.
If you're running a high traffic site where consistency matters, this is something you'll want to consider. If you can deploy during off hours when there is little/no traffic, then php vars or other standard text formats will be fine.
I like the idea of having "namespaces" or some kind of tree
so you can have:
db.default.user
or
db.readonly.user
and so on.
now regarding code what I did was an interface for the config readers: so you can have a memory reader, array reader, db reader, etc.
and a config class that uses those readers and allow you have a config from any kind of source