I am solving a problem: I have a ZF2 Skeleton application which runs fine, service manager, db adapter, routing, everything is fine. But what I need to solve is how, when or how better load some configuration (settings) from database?
The point is (AFAIK) to have the Zend configs that are not visible nor editable from outside (or let's say via administration). But I need to have the ability to administer many configuration settings - and these should be loaded also on the startup (bootstrap, whatever). These settings could be managing e.g. widgets displaying (let's assume that almost every block on the website is controlled by widget - view helper - and I have to decide - via configuration - whether to display that widget or with what additional settings).
What I would need to help with is how to manage this configuration that will be loaded from DB.
should I merge it with Zend config?
should I load it in module's onBoostrap?
should I use better solution (what)?
I was thinking of having editable PHP config file (that will Zend simply load with other config files) so that administering these settings would lead to reading from and writing to a file but this is really a bad idea as there is possibility of more simultaneous edits for which purposes the database handles this far better.
Your module.php should have a function getConfig() which returns an array. You should be able to modify it in such a way to fetch your config key/values from the database.
Related
I've a very basic question which drives me nuts. I maintain my own little framework. I can configure the framework with a YAML/JSON/XML/whatever settings file. The framework uses also a cache (any of memcached/couchbase/whatever even file based caching if no caching server is installed).
So no I've the following problem: I like to cache my settings parsed from the settings file in the cache but I would like to define the cache type used for that in the settings file.
What would be a proper solution for this? I can't imagine how I should manage this which leeds me to the thought that I probably have a very basic design / architecture error in my framework. Is there any solution at all?
Well as my experience from Symfony1 and Symfony2 goes, cache as much as you can.
In their production environment everything is cached, so you would run into your problem that the cache type is described in the settings file which is itself cached.
The proper solution to this is: As in Symfony: Delete the cache in prod, once you made changes to settings.
For dev the settings are always re-read as you do not profile in debug, so ease of development is more important that bootstrap time.
I recommend splitting this like symfony did.
For prod your settings are seldomly changed so parsing a file that can be cached is wasted resources and speed is typically priority 1 in prod.
Edit: Your options regarding the order of bootstrapping:
Always read settings first then decide which cache you will need.
Use a settings configuration cache that is hard coded (e.g file based)
I recommend using option 2. Your framework is cache agnostic as this can be configured, which is good but for basic settings of your framework you simply do not need that. You don't want to setup different cache mechanisms like memcache, sql etc just for basic settings.
Symfony solves this by the most effective way, as it provides a default cache generation for settings and this is simply a php file. Thats all. When symfony loads settings it looks for a certain file to include, if it does not exist, symfony caches it by creating plain php and then reads it.
You can determine the file type from the file extension. Then you can read the cache type and create a cache. The cache should be a singleton.
For the creation of the cache I would use an abstract factory, which implementation is dependent on the file type. The appropriate implementation of the abstract factory then can read the settings file and create the right cache.
I want to have a bunch of settings in my module, and they should be writable from the App. Since they're application settings, I thought a table for it would be not very efficient (it would only have one row).
I found the Zend module Zend\Config, which seems to be able to to write config files, which can in turn be used by Zend.
It is advisable to write into the module.config.php? Or into a different file? Can I still load it into the standard module config?
I am pretty new to Zend and this fully modular approach, so I'd like some clarification on that.
You should never write into the module directory itself. Instead, have a data directory, e.g. at the root of your application, and put written configuration files in there.
I am a Zend developer. I just want to know the real purpose of the application.ini file. As far as I understood, it is used to specify the locations of controllers, views, models, modules, session and library files (Acl & VanityUrl) and to Connect to database. Anything else about it? Please help me if you have something else.
Cheers...!!!
Its a Configuration file,
Every configuration to the project is defined in this file in a
specific format.
It handle error display, bootstrap file handling.
All the controller files handling and all the above mentioned in
your question itself.
You can also define the configuration as per server i.e. production
server, development/testing, staging server etc....
All the permission hanlding to any specific functionality is done
here.
Newly installed Plugins in framewirk needs to be registered here in
application.ini file.
Routing is also configured herein application.ini file
I hope above are few of the "something else" points you were looking for... Cheers!!! :)
As you stated, you can use it to configure many aspects of your application through one of the Resource Plugins. In addition, you can configure php.ini options, configure Routes, and set options for your own application.
It is also possible to have an empty application.ini and configure everything in the Bootstrap, but the application.ini file is much easier to read and make changes to than it would be to do all of that in the bootstrap. And with the help of the resource plugins, it is often much easier to configure them in the ini file instead of in code.
I want to write a php application using Zend Framework 2 (just the beta 2 yet).
Because it's going to be a collection of several webservices I decided to seperate it into different modules (with own databases).
Before starting to write the first module I want to write the code wich each module should need. For example the layout. Each module uses the same layout. That's why I want to write it globally to improve the development process of single modules.
How can I provide defaults for each module globally? (e.g. layout, plugin, default database model, ...)
In ZendFramework2 configurations from all modules are always merged.
Additionally there is a global config which can overwrite module-wise config.
So including a vendor module brings in a default configuration you can and should overwrite via your global config.
The global config may consist of multiple files making it easy to distinguish between modules-to-be-configured.
The first example I have is an article of akrabat about module configuration and overrides.
Another nice example of this pattern is Akrabat's quickstart (https://github.com/akrabat/zf2-tutorial):
one App module, based on ZendSkeletonApp
one Album module, the part you actually did.
In the App module there is config for the basic routing, Views and the Layout are set up
In the Album module there is only the set-up for Album-specific things (e.g. dependency injection), the view and routing are used from the App-modules config.
You may decide to overwrite this config on a per-module basis or globally, in the default project layout your configs are placed like this:
/config/application.config.php the base configuration
/config/autoload/*.config.php may be used to overwrite modules or app config (e.g. for local development)
/module/[your-module]/config/[your-module].config.php the default configuration of your module
/vendor/[vendor-module]/config/[vendor-module].config.php a module you dropped in, but has definitions for it's dependency injection. if it uses e.g. a database you want to overwrite some parameters in your /config/autoload/*
I am creating a custom magento module and cant decide the best place to store some config files i require with the module?
Anyone out there suggest the best place for this? Should it be in the root of the module or in with the helpers maybe?
Edit:
Along the same lines as this question: is it acceptable to have a folder in the root of the namespace for the modules for includes that will be shared amongst the modules?
If these files are for configuration, they belong in etc. Think of the etc folder the same way you would a unix/linux/bsd system's etc folder. It's where you put configuration information. Convention is that you should use an XML file to hold your config data, and then load it with
Mage::getConfig()->loadModulesConfiguration('your-xml-name-here.xml')
When you use the loadModulesConfiguration method to load your configuration values, Magento combines XML files for ALL modules in the system into one big tree. This allows other modules you'll write (or others would write) to share the configuration information.
You don't need to do this, but etc is definitely the defined place for any configuration files you want to include with your module. Also, whatever method you're choosing, I'd pick a unique file name (packagename_modulename.xml, packagename_modulename.inc, etc.) to ensure against the slim possibility that someone at Magento might pick your name to use in a future version.
Along the same lines as this question: is it acceptable to have a folder in the root of the namespace for the modules for includes that will be shared amongst the modules?
No, that would not be acceptable. If you want a shared configuration, use the method I mentioned above. If modules need to share other information with each other, they should either do so directly (one module instantiates another module's model) or you should define a central "broker" module that handles all inter-module communication. If you're interested more in the topic, I'd recommend the first few chapters of Meyer's Object-oriented Software Construction. If you can get past the whole "how to implement low level data structures" aspected of old programming books, its a great introduction to what CS people when they say "module".
(it's also worth mentioning that if there are simple configuration values, learning how to use the Magento System Config Admin section is worth it.)
You could probably get away with this, but you're purposely avoiding Magento to do so. Inside a module, make a directory called etc and put an XML config file in it called config.xml. That file will be read and included in the Magento configuration, which means you won't have to try to escape the framework to grab your configuration data. Take a look at the existing files for some examples.
The other benefit to this approach is that the conversion from config XML files to user configuration options (in the admin panel) isn't too difficult (requires minor refactoring), so you can later change your configuration method with ease.
Hope that helps!
Thanks,
Joe