Improving on this question:
Is it good practice to add own file in lib/Varien/Data/Form/Element folder
The accepted answer shows how to extend a Varien form element, but this will not work if you want to package it into a custom module.
What would be the proper method of extending the Varien form element in a module? A simple XML setting I'm hoping?
Update:
Thanks Vinai for the response. Although that does work, I was hoping to extend the form element somehow. My extension is using the base File form element to allow administrators to upload files to categories. So, I'm not directly adding the form elements to the fieldset myself.
I suppose it's possible to to check for the file input on my category block on the backend: Mage_Adminhtml_Block_Catalog_Category_Tab_Attributes , and then change the form element if it is 'file' to 'mycompany_file' -- but this seems like a workaround.
Is there an easier way? Thanks again Vinai.
On the Varien_Data_Form instance you can specify custom element types like this:
$fieldset->addType('custom', 'Your_Module_Model_Form_Element_Custom');
Then, add your element with
$fieldset->addField('the_name', 'custom', $optionsArray);
If you are using a form without fieldsets you can do the same on the Varien_Data_Forminstance, too.
EDIT: Expand answer because of new additional details in the question.
In the class Mage_Adminhtml_Block_Widget_Form::_setFieldset() there is the following code:
$rendererClass = $attribute->getFrontend()->getInputRendererClass();
if (!empty($rendererClass)) {
$fieldType = $inputType . '_' . $attribute->getAttributeCode();
$fieldset->addType($fieldType, $rendererClass);
}
Because of this the attribute frontend_input_renderer on the attributes can be used to specify custom element classes.
This property can be found in the table catalog_eav_attribute, and luckily enough it isn't set for any of the category image attributes.
Given this, there are several ways to apply customizaton.
One option is to simply set the element class in the table using an upgrade script.
Another would be using an observer for the eav_entity_attribute_load_after event and setting the input renderer on the fly if the entity_type_id and the input type matches.
So it is a little more involved then just regular class rewrites in Magento, but it is quite possible.
You don't necessarily need to have a file in the lib/Varien/ directory in order to extend it. If you needed to add an element to that collection, you should be able to extend one of the Elements in your app/code/local module. The answer to the question you referenced seems to also indicate this is the case. I would create your custom field, extending its highest-level function set (i.e., lib/Varien/Data/Form/Element/File.php).
If you want to override the Mage_Adminhtml_Block_Catalog_Category_Tab_Attributes block, then you should extend that block in your module and then reference the new one. You may wish to extend the block using an event observer rather than an XML rewrite, for compatibility purposes.
Related
I need to edit a page on prestashop, I've found that code
<ul id="idTab2" class="bullet">{$agencies->content}</ul>
And where should i search for that $agencies variable ?
I have found the text which is being displayed into that place in CMS.
However I'd that variable need to be define somewhere, am I right ? Anyone knows where should i search for that ? I'm new to prestashop.
Why am i asking for this ? I need to add another page for example
<ul id="idTab2" class="bullet">{$test->content}</ul>
- but I can't just simply add another page called test.
The {$agencies} variable is being set in a object derived from either the Controller or Module classes but to be honest it looks like you're working with code that has been customised (via a class override or a module) making it impossible to provide a definitive answer to your question without knowing more detail.
If you can locate the term 'agencies' in a file located under \controllers, \modules or \override in your installation, then you will be closer to finding your answer. It will be contained in a function call similar to:
$this->context->smarty->assign('agencies' , [some-variable]);
Note that the parameters to the function may also be passed as an array for multiple assignments.
More of a best practice question as I don't want to start down the wrong path.
The following link from the Magento Wiki shows how to add Attribute sets programmatically: here.
It also seems you can use the class Mage_Eav_Model_Entity_Setup and access the methods within to add the attributes etc i.e
$groupSetup = new Mage_Eav_Model_Entity_Setup('core_setup');
$groupSetup->addAttributeSet($entityTypeId, $name);
In my mind, the second option is quicker and simpler but is there a rule on how this data should be added? i.e Is one option likely to change whereas another isn't?
I'm creating a widget where there will be 2 types of params:
-The one that can change depending on where we call the widget, those one will be defined in the widget call:
<?php $this->widget('ext.myWidget', array(
'someParams' => 'someValues',
)); ?>
-The one that are the same for all the call to the widget (a path to a library, a place to save an image, ...)
I would like to know what is the best way to define the second type of parameters.
I'm hesitating between making the user define it in the params array in the config file or defining it in an array in the Widget file.
The main advantage of the first option is that the user won't have to modify the Widget file so in case of update his modifications won't be overwritten, but this is not a specific user params so putting it in the parmas array in config file might seem strange.
So what would be the best solution? If there is another one better thant the 2 above please tell me!
Edit:
To clarify my thought:
My widget will generate some images that can be stored in a configurable directory. But since this directory has to be the same each time the widget is called I don't see the point of putting this configuration into the widget call!
This is why I was thinking about putting some params into the config file, in the params array like:
params => array(
'myWidget' => array(
'imageDir' => 'images',
)
)
But I don't know if it is a good practice that an extension has some configuration values in the params array.
Another solution would be to have a config.php file in my extension directory where the user can set his own values so he won't have to modify his main config file for the plugin. But the main drawback of this alternative is that if the user update the extension, he'll loose his configuration.
This is why I'm looking for the best practice concerning the configuration of a widget
Maybe what your looking for is more of an application component than a widget. You've got a lot more power within a component that you have with a widget. It can all still live in your extensions directory, under a folder with all the relevant files, and still be easily called from anywhere but the configuration can then be defined in configuration files for each environment.
When your setting the component in your configs, just point the class array parameter to the extensions folder, instead of the components folder.
Update:
If you do want to use a widget because there's not a lot more complexity, you can provide some defaults within application configurations for widgets I believe, I've never used it myself, see here: http://www.yiiframework.com/doc/guide/1.1/en/topics.theming#customizing-widgets-globally.
But I've found with more complex widgets that a component serves me better in the long run as I can call methods and retrieve options on it much easier and cleaner, but still have everything related to the extension within one folder.
I created a module with an observer for the sales module with event hook ‘sales_order_shipment_save_after’ ,
My module has the following files
Company/Modulename/etc/config.xml
Company/Modulename/etc/system.xml
Company/Modulename/Model/Observer.php
there are four fields in the modules admin configuration fields
I want to get those saved data in the Observer class.
using $this->getConfigData(’password’); gives a
Call to undefined method
error
Any suggestions?
Magento uses a static method on the global Mage application object to get configuration values
$config = Mage::getStoreConfig('section_name/group/field'); //value
$config = Mage::getStoreConfig('section_name/group'); //array
An amendment to Alan's completely correct answer.
Along with path as first parameter, getStoreConfig also accepts storeid as second parameter(optional).
Well, this is useful when you want to retrieve store-wise values.
Alan has mentioned this point in his own tutorial. I guess, he has not mentioned here just because OP has not mentioned this requirement in his question.
Please refer this
In a shipment module I can use $this->getConfigData for fields in system.xml, but in another kind of modules sometimes not, e.g. extends Mage_Core_Model_Abstract, than I must use getStoreConfig. So the answer is you don't have to use always getStoreConfig. But I don't know why ...
Answer: getConfigData is just defined in a shipment class and uses getStoreConfig too. A little confusing that some functions are extra defined and unneeded in fact ...
How do I tell the Zend_Form that I want an element (and it's ID-label, etc) to use another ID value instead of the element's name?
I have several forms in a page. Some of them have repeated names. So as Zend_Form creates elements' IDs using names I end up with multiple elements with the same ID, which makes my (X)HTML document invalid.
What is the best solution to fix this, given that I really have to stick with using the same element names (they are a hash common to all forms and using the Zend_Form Hash Element is really out of question)?
Zend_Form_Element has a method called setAttribs that takes an array. You may be able to do something like $element->setAttribs(array('id' => "some_id"));
or you can do $element->setAttrib('id', 'some_id');
Thanks, Chris Gutierrez.
However, as I said, I needed to get ride of the default decorator generated IDs like -label. Wiht the $element->setAttribs() it is not possible, however.
So based on http://framework.zend.com/issues/browse/ZF-7125 I just did the following:
$element->clearDecorators();
$element->setAttrib('id', 'some_id');
$element->addDecorator("ViewHelper");
Whoever sees this: please note this was enough for what I needed. But may not be for you (the default settings has more than the viewHelper decorator).