I want to add format pattern to format dial numbers as an xml file to the data directory of zend_locale_data. At the moment there are no format patterns available via CLDR, so i want to add it to my local zend framework environment.
As mentioned here, comment of Thomas Weidner at 26/Nov/07 2:04 AM, there is a way, but I can not find the file (file name is not written in that post) in the data directory (not in ZF 1.0.2 or in a newer one: e.g. 1.11.3).
I can not extend the Zend/Locale/Data.php and add a new case "dialnumber" to the switch-case in getContent(), because there are some private vars used (instead of protected) in getContent().
How to add a own "dialNumber.xml"?
Related
I have a system.xml in my module, which starts with this:
<config>
<sections>
<dev>
<groups>
<my_module>
<label>...
I want to get the value of this label, from a different module. How do I do it? My first thought, was Mage::getConfig('sections/dev/groups/my_module/label'), but this doesn't work - it seems the <sections> area of the config is not accessible. I also can't figure out where magento is loading this value, which it must do at some point, or it wouldn't be able to display it.
To be completely clear: I am not trying to get the config data value as stored in the core_config_data table, that's no trouble. I want to be able to get the other attributes relating to it - like the group label, or the sort order of the fields, and to do that I need to be able to read the <sections> area of the config.
The system.xml files are never merged with the global configuration. They're only loaded when Magento builds the user interface for the
System -> Configuration
section of the backend admin application. Other than that the application has no use for them.
If you want to grab the label, you'll need to load the full system.xml configuration yourself. Something like this should work.
//load and merge `system.xml` files
$config = Mage::getConfig()->loadModulesConfiguration('system.xml');
//grab entire <sections/> node
var_dump($config->getNode('sections')->asXml());
//grab label from a specific option group as a string
var_dump((string)$config->getNode('sections/dev/groups/restrict/label'));
As mentioned in another answer in this thread, there's also an adminhtml/config model class which wraps some of this logic in a getSection method, so you could do something like this.
Mage::getSingleton('adminhtml/config')->getSection('dev')->groups->my_module->label
If you look at the source of getSection
#File: app/code/core/Mage/Adminhtml/Model/Config.php
public function getSections($sectionCode=null, $websiteCode=null, $storeCode=null)
{
if (empty($this->_sections)) {
$this->_initSectionsAndTabs();
}
return $this->_sections;
}
and follow the call stack through to _initSectionsAndTabs
#File: app/code/core/Mage/Adminhtml/Model/Config.php
protected function _initSectionsAndTabs()
{
$config = Mage::getConfig()->loadModulesConfiguration('system.xml')
->applyExtends();
Mage::dispatchEvent('adminhtml_init_system_config', array('config' => $config));
$this->_sections = $config->getNode('sections');
$this->_tabs = $config->getNode('tabs');
}
You'll see this wrapper method eventually calls the loadModulesConfiguration method itself. The additional applyExtends if an old bit of meta-programming in the configuration you can read about here, which is part of a longer series on configuration loading. (self-links, too long for a StackOverflow answer).
The reason I personally wouldn't use this to grab values out of the configuration is the event that's dispatched when you make this call
Mage::dispatchEvent('adminhtml_init_system_config', array('config' => $config));
This event may trigger code in your system that assumes you're loading the system configuration system in the backend admin console area. If you just want to read the XML tree. simply loading it yourself and reading the values seems the way to go. Your use case, of course, may vary.
As so often seems to be the case, I find the answer moments after posting the question...
This is how to get sections/dev/my_module/label:
Mage::getSingleton('adminhtml/config')->getSection('dev')->groups->my_module->label
As you can see, you need to use Mage::getSingleton('adminhtml/config')->getSection('dev') to get the backend config (you can also use ->getSections() to get all the sections to iterate over). This returns a Mage_Core_Model_Config_Element Object, which is the root of a tree of objects, accessible as shown. Just do a print_r at any stage and you'll see the rest of the tree, which print_r formats like an array, although it's not.
I'm working on my own module. I realize I constantly need to manually type my module name in different places. Most popular usage is with drupal_get_path($type, $name) function (I have more then 10 of these in my code). Where $name is theme or module name. During that time I need to already change my module name 3 times. As you can surmise I also need change all module names hard-coded in my project. So I thought it would be nice to have some convenient function to grab this name automatically.
How can I get machine module name programmatically?
For example if you have your module in following directory..
sites/all/modules/my_module/
..then you can grab it in this way
drupal_get_current_module_name(); // return my_module
Generally, you should know by convention - if you have: sites/all/modules/my_module/ then the machine name of the module should match the folder name - my_module.
Virtually all contributed modules follow this convention, and you should too.
It is possible to have your .info and .module file not match the name of the folder, but this isn't correct.
If you are already executing code inside your module, you should already know the machine name of the module by virtue of the name of the file you're editing - unless you're trying to do something that I'm not understanding.
Edit: Since we've determined you're just trying to call your module's theme function, you don't actually need to know the name.
If you have:
/** Implements theme_table **/
function my_really_long_module_name_table() {}
Your function might get called like this:
theme('table');
There is a little more to it than that, but the theme engine will make a determination about which theme functions get called based on what is implementing them.
It sounds like you may want to read up on some of the basics of the Drupal theme system.
Here's a good start for learning the Drupal 6 theme layer: http://drupal.org/node/165706
I figure out something like this:
function get_current_module_name() {
return array_shift(explode('.', end(explode(DIRECTORY_SEPARATOR, __FILE__))));
}
but don't know is't the best way to do it..
UPDATE:
I see now it's better to use basename
$name = basename(__FILE__, '.module');
UPDATE 2:
I think if this is needed across whole module then it could be accessible via constant defined in the very beginning of the module e.g.:
define('MODULE_NAME', basename(__FILE__, '.module'));
Then you could use all the time in all your function like this:
drupal_get_path('module', MODULE_NAME);
I can edit a PHP Class template through 'Tools' > 'Template Manager', and then 'PHP Class' > 'Edit'. My project's framework supports autoloading using namespaces, so i want to automatically add a namespace to the top of the file whenever i create a new 'PHP Class'. How can i do that?
And as a side, how can i find out what variables are available to me in a template?
UPDATE: That was quick! I will admit to very shoddy testing here, but it works if you use New -> PHP Class... through the UI. Then you select the namespace in the drop-down. Et voila. I was using New -> PHP File... which does not provide the namespace drop-down (oddly, or maybe I just missed something). Customise the PHP Class template as needed. Sorted.
I have been scratching my head about this too and found the following bug report. According to the instructions (towards the bottom), you edit the template file and add:
<#if namespace?? && namespace?length > 0>
namespace ${namespace};
</#if>
Then Netbeans makes a guestimate based on the files location and other possible namespaces in the directory. To be honest though, I have quite managed to make it work yet but I'm sure I'm not far off... probably... U_U
I'll be sure to update this if I do.
SIDE NOTE: You can add any variables you want to a template. Go to (on windows) \AppData\Roaming\NetBeans\7.4[your version here]\config\Templates\Properties\User.properties (create it if it's missing)
Then create something like this:
user=Ms Angelina Jolie Lookalike Honest <no.spam.thanks#gmail.com>
organization=the.Evolution.of.Awesome
package=SunshineInACan
package2=Framework/UserInterface
Then in your template do something like this:
/**
* #DNADO Type description
*
* #package ${package}.${package2}
* #subpackage
* #category
* #author ${user}
*
* #copyright ${date?date?string("yyyy")} ${organization}
*/
Then... disco ;)
What I also do to save a bit of time is put common options in one variable and just delete as applicable after I create the file. For example ${package2} is either 'Framework' or 'UserInterface' not both (or both if I forget, you know how it goes).
I remember editing default class template causing some problems and I ended up creating new class template for my needs. You can do it by selecting existing class file and running 'save as template' from context menu
As for available variables:
Variable Name Description
name contains the name of the file that is being created
user contains the user name
nameAndExt contains the name and extension of the file that is being created
date contains text representing the current day like 23. 3. 2007
time contains text the current time like 17:18:30
encoding the file encoding of the template instance
Useful references:
http://blogs.oracle.com/netbeansphp/entry/how_to_manage_templates_in
http://blogs.oracle.com/netbeansphp/entry/how_to_manage_templates_in1
namespace include.class you can use the classes same as include and requires funciton
I've got a Zend-Framework application. I'm using the module-structure which Zend_Controller_Frontprovides. Here is a small excerpt from my directory-structure (only the important parts for this question):
root-directory
- modules
- blog
- views
- scripts
- index_index.phtml
- views
- pagination_control.phtml
As you can see I've got view-scripts that are specific to a module/controller/action. These views are located in the corresponding path (in this case like modules/blog/views. I've also got a more general view-directory located in the root-direcetory of my application.
What I am doing now is to call the PaginationControl-ViewHelper in modules/blog/views/scripts/index_index.phtml. This View-Helper however renders a partial-view, as you know. The ViewHelper tries to locate the partial-view within the same directory (meaning modules/blog/views/scripts. Since I want to use the same view-partial-script (pagination_control.phtml) in different modules I want to make this view-partial accessable from each module. So I want to put that file in the general views-folder in the root-directory.
However this doesn't work. The ViewHelper always looks for the view-script in the corresponding module-folder.
Anyone can help to make it accessable from my general views-directory?
As you can see here, since ZF 1.6.2 pagination control can take an array instead of a string for the partial argument, and in this array you set 1st the name of the partial and in 2nd the module name. This is still undocumented.
Using an array you can specify a module ('common'?) for the partial to use.
The real call will be (with $partial your 3rd argument to the paginationControl() view helper ):
$this->view->partial($partial[0], $partial[1], $pages);
This is usefull if you have a 'common' module.
Now here you are using a shared folder. You shoudl have installed it as a shared folder for your Zend_View this way (in a Boostrap or ressource code):
$view->addScriptPath("/root-directory/views");
or better:
$view->addScriptPath("/root-directory/views/partials");
And then you should'nt be required to specify any module directory. Zend_View should always check for a partial in this folder.
I'm building an MVC framework in PHP that will need to set a number of default configuration variables/constants. Example config vars would be where to save log files, whether to log queries, Doctrine settings, amongst many others. Because I want developers to be able to create new projects with minimal fuss, these config vars should have default values. However to make this framework truly useful, I need them to be able to override these default values either in a project bootstrap file, or from within a controller or model. I would love to use constants, but they cannot be overwritten. I feel as though there must be a simple solution that I just don't see (perhaps a design pattern?). Any advice would be greatly appreciated, thanks.
In a situation like this, I would probably :
Create a class that deal with everything configuration-related
That class would contain methods to get/set configurations options ; whatever your application needs
It would also define default values, when suitable
Use a .ini or .xml file, in which configuration values can be re-defined
When instanciating the class :
You already have the default values
You parse the .ini or .xml file
Each value defined in that configuration file is used to override the corresponding default value that what defined in the class.
A solution a bit more complex, but maybe better, might be to :
Still have that configuration class, but not use it to store any default values
Have one .ini or .xml file to store default values
Have one .ini or .xml file in which people can override the values defined in the default one
Load the file containing the default values, and then the one containing the specific ones
Advantages of this solution are :
No configuration value stored in a PHP class
All configuration options that can be overriden are already defined in a .ini / .xml file, which means people just have to copy/paste a line to their specific file to override : no need to go take a look at the PHP class and think "how do I translate this to a config file ?"
A couple more notes :
You might want to use some kind of caching-mecanism, to not re-parse the files at each request
Zend_Config and Zend_Config_Ini might be helpful ; even if you don't use those, as you are writing your own framework, you might want to take a look at what they do -- If I remember correctly, Zend_Config_Ini allows for hierarchy and inheritance in .ini files
Have fun!
I'd suggest using several ini files: a default.ini, and then as much override.ini-s as you need. Then simply load them with parse_ini_file() and merge into one config with array_merge(). Quick and simple.
Here's the design pattern I would use. I would create a simple class to facilitate it:
class Configuration {
String get($key) {...}
String set($key, $value) {...}
}
Initial implementation could all be hard-coded with default values. Later, though, you could slip in the reading of a server and/or project specific configuration file. It would give you flexibility to add as needed.
(I also noticed that the php.ini configurations seem to have the behavior you want, but I don't see how you leverage that system directly.)
This question can come with a wide variety of answers. My personal recomendation would be to store values into SQLite and have a seperate script to access and change those values. For other way continue to read.
This is pretty simple depending on how object oriented you want to be and how simplified you want to make things for your users. Your install instructions could simply instruct users to edit a file directly. In which case you could simply instruct users to edit a file of constants directly.
Most applications that follow this route implement it with detail explination
<?php
/**
* Global application configuration
*/
class AWConfig {
/**
* true or false
* If the is set to true debug messages will be added to the application logs
*/
public $DEBUG_MODE = true;
/**
* Path to Station database
* ex (/homepages/26/3/htdocs/databases/stations.db)
*/
public $DB_STATION = '/homepages/26/3/htdocs/databases/stations.db';
/**
* Path to logs database
* ex (/homepages/26/3/htdocs/databases/stations.db)
*/
public $DB_LOGS = '/homepages/26/d175338743/htdocs/weather/dev/metrics/beta2/databases/metriclogs.db';
/**** DO NOT EDIT BELOW THIS LINE *****/
public $LIST_STATION_LIMIT = 10;
public $MAX_COMPARE = 6;
}
?>
If you want to hide these details from the user than an initial setup script would be best that would prompt user for details and write a file (config.php, config.ini, config.xml, or to a database) the settings they chose. Then a different script to edit in the future. Good example would be Joomla CMS.