Having difficulties extending Zend_Form - zend-framework

Currently I have big difficulties extending Zend_Form.
I have the basic class called Forms_LpaManageEmailForm.
It is used separately and works fine.
Next I've created a new class form
called Default_Form_CartReport witch extends Forms_LpaManageEmailForm.
So the task is to render Default_Form_CartReport and slitely modificate it.
In other words I need all functionality of
Forms_LpaManageEmailForm class but with overriden _addMultiOptionsForMultiSelect() function
(what is done) and changed button label (doesn't solved).
In basic class I have hidden element named id which value is filled with
$this->_entry_id['entry_id']. When I use basic form separately - its woks fine. But
when I run extended form(Forms_LpaManageEmailForm) I see that hidden id element's value is empty. In basic class in construct section I run
Zend debugger(with this line Zend_Debug::dump($this->_entry_id['entry_id'])) to see if the
value is passed. And it's passed :) When I repeat this in init() section it shows NULL...
As I barely understand - the problem lays in init() functions, in the way it is called.
I think something is wrong with Default_Form_CartReport class skeleton.
I've uploaded code to: PASTEBIN
Really need help in this question.
Thank you!

I believe your issues are causing my the fact that Forms_LpaManageEmailForm:: __construct is calling $this->init() directly. if you open the Zend_Form, you will notice that the __construct is also calling the $this->init() function. This cause your init() function to executed twice.
Try to load all your logic & elements solely in the __construct function, and don't use the init() function. also, the __construct function in each form class should always call the parent::__construct before any additional logic.

Related

Understanding Zend_Controller_Request_Abstract and other core Zend classes

I am digging deep into the Zend framework and at this point I am a little confused. I am particularly checking out the Zend_Controller_Action (*_Action), Zend_Controller_Request_HTTP(*_HTTP) and Zend_Controller_Request_Abstract (*_Abstract).
The *_Abstract class as it's name suggests is an abstract class hence cannot be instantiated and mostly provides method stubs along with a few final implementations. The actual implementation is in *_HTTP and *_Simple classes that subclass *_Abstract. Fair enough.
Now I am looking at the *_Action class, right here: http://framework.zend.com/apidoc/1.0/Zend_Controller/Zend_Controller_Action.html
Taking a look at $_request variable, it states that it is an instance of type *_Abstract. At this point, I am confused since I do not know why it should be of type *_Abstract and not *_Http since one cannot technically have an instance of an abstract class.
So my question:
Why is an instance of an abstract class being declared here.
Moving on, I want to override the $_request classes's getParams() method since this is how our application retrieves all parameters and I would like to apply some common sanitization and blacklisting rules to all of our input right here.
Unfortunately, when in my BaseController (the Main Controller that is subclassed by all other controllers) I declare something to the effect of :
$_request = new RequestClass(); //RequestClass subclasses Zend_Controller_Request_Http and overrides getParams()
my application does not launch itself the way it ought (I get a blank screen).
For those more curious, RequestClass() getParams() does nothing fancy but:
getParams()
{
$params = parent::getParams();
//sanitization rules over $params;
return $params;
}
The type hint of Zend_Controller_Request_Abstract effectively means the request must be an instance of a class that extends Zend_Controller_Request_Abstract.
Unless you're delibrately not using ZF's routing, you'll probably be better off doing your sanitation of parameters through the routes. Otherwise, if you're getting a blank screen, that means display_errors is turned off and the PHP error or exception is being logged instead. Check your web server error log to see what the actual problem is.

Magento: Accessing models/blocks from a phtml

Hi I have a situation where I need to look up the number of recently viewed products on catalog/product/view.phtml. In the recently viewed 'product_viewed.phtml' file it calls
$_products = $this->getRecentlyViewedProducts()
to get the recently viewed. How would I access this method from within the catalog/product/view.phtml file?
I don't know where this method is. I've tried searching for it but it doesn't seem to exist. When I write click it in Netbeans and click go to declaration it takes me to
class Mage_Reports_Block_Product_Viewed extends Mage_Reports_Block_Product_Abstract
Actually on the class itself. This class only has _toHtml(), getCount(), and getPageSize() methods.
I just need to know whether there are any recently viewed products.
Any help most appreciated!
Billy
If you look into 'Mage_Reports_Block_Product_Viewed', you will notice:
$this->setRecentlyViewedProducts($this->getItemsCollection());
That 'getItemsCollection' method is defined in the abstract class... And you will notice this abstract class will create a model based on $_indexName defined in the (subclassed) block.
If you just want the collection, you can probably get away with:
$_products = Mage::getModel('reports/product_index_viewed')->getCollection();
And then adding whatever you want to the collection:
$_products
->addAttributeToSelect('*')
->setAddedAtOrder();
// optionally add other methods similar to Mage_Reports_Block_Product_Abstract::getItemsCollection
Another approach that might be more suited would be to create the original block:
$productViewedBlock = $this->getLayout()->createBlock('reports/product_viewed');
On which you can simply call whatever you want:
$_collection = $productViewedBlock->getItemsCollection();
$_count = $productViewedBlock->getCount();
The getRecentlyViewedProducts function is a magical getter that gets the data that was set with setRecentlyViewedProducts in app/code/core/Mage/Reports/Block/Product/Viewed.php (which builds it using app/code/core/Mage/Reports/Block/Product/Abstract.php's function _getRecentProductsCollection).
This is complicated stuff that you don't want to reproduce; its better, IMO to make your own Block that extends Mage_Catalog_Block_Product_Abstract that will give you access to the same functionality, and drop your new block into the page you're working on.

Static methods & inheritance in Coffeescript

I've been reading up a bit about coffeescript's inheritance model and I have the feeling I'm on the fringes of an ideological debate which I really don't understand. So, I would be perfectly happy to find out that I'm just doing things in the wrong way.
Basically what I am doing is writing a set of widgets which, among other things, need to handle events on their DOM elements. I thought a good way to go about this would be to have a class method which would be called once, to delegate all the events which the widget might need. The base widget class might have some simple click handlers, while the subclass might add to that some mouseover handlers or extra click handlers.
However, it appears that I'm not supposed to try and do the equivalent of calling super() inside a static method. There is a workaround which exists, (this.__super__.constructor.METHODNAME() but I've seen a lot of suggestions that this isn't the best way to do what I'm trying to do. Has anyone got any insights on how I should structure this code? Keep using the workaround, or put all the delegation into a totally different place? I can't really just stick it in the prototype, since I won't necessarily have an instance to call the method on (or can I essentially still call a method on the prototype from a static context, like putting SwatchableWidget.prototype.delegateEvents() into an onload function or something?
Here's a bit of code to illustrate what I'm talking about:
class Widget
#testProp: "ThemeWidget"
#delegateEvents: ->
console.log "delegate some generic events"
class SwatchableWidget extends Widget
#testProp2 = "SwatchWidget"
#delegateEvents: ->
console.log "delegate some specific swatchable widget events"
this.__super__.constructor.delegateEvents()
Widget.delegateEvents()
SwatchableWidget.delegateEvents()
Thanks for any help.
I suggest replacing
this.__super__.constructor.delegateEvents()
with
Widget.delegateEvents()
trying to use super to call static methods is not required (and doesn't make much sense)
I don't understand why delegateEvents would be a class-level method, or why Widget.delegateEvents have to be called again from SwatchableWidget.delegateEvents. If it's just class initialization code, you should put it in the class body directly:
class Widget
console.log "delegate some generic events"
...
#testProp: "ThemeWidget"
class SwatchableWidget extends Widget
console.log "delegate some specific swatchable widget events"
...
#testProp2 = "SwatchWidget"
I take it you're waiting for a specific DOM state before running this initialization code? Maybe I could suggest another approach if you told me a little bit more about the preconditions for delegateEvents.
It sounds like you want a different type of inheritance model where each inherited function of a certain type ("parent calling") will walk the inheritance tree and call all its parents with the same name.
You could call any direct parent functions in each child manually as you've written. Then it will float up the inheritance chain anywhere you specify such a relationship.
I would bind the parents delegate call in the constructor to a current class function
delegateparents =>
#call any parent class methods

DelegateCommand<object> test with EventArg parameter mstest

I currently have an event trigger firing a custom trigger action.
The action passes back a EventArgs type of object to the view's view-model.
This is all well and good when I run the code it works perfectly. However, when I come to test this portion of code it all goes a bit rubbish.
As stated We are using an MVVM type pattern so I'm testing the 'Doing' end of the event trigger in my view-model and what I want to do is create a 'mocked' EventArgs object to pass into the execute method of my command under test. However it requires a RoutedEvent as it's ID property as stated above and I don't have access to it's constructor!
Cannot Access Internal Constructor for 'RoutedEvent' here.
Has anyone got any ideas? The code converage in test is more important than the current implimentation so if this is thought to be 'untestable', then I can make changes.
I have answered my own Question I think.
Casting the object passed back from the view at an earlier point means that the object I am passing to the methods under test is more easily created.
This is what I have now for the method under test.
public void DoItemsChanged(IList param)
Before I had
public void DoItemsChanged(object param)
Where the param is a SelectedItemCollection (previously a RoutedEventArgs, but now I use the IvokeCommandAction on the event trigger in the view, passign the SelectedItems). The param is now more easily passed into the method for the test and the code it much more descriptive as well. So it's all good for everyone.

zend_form access parent form element

I couldn't find any reference on how to use a parent form element in a subclassed form. May be because it's obvious to everyone but me. It's got me stumped. This is what I tried.
At first, within my form constructor I called
parent::__construct($options = null);
then accessed the parent elements like this
$type = parent::setName($this->type);
The problem was that ALL the parent form elements would display whether explicitly called or not. Someone said, "don't use __construct(), use the init() function instead. So I changed the constructor to init(), commented out the parent constructor, then ran the form. It bombed saying it couldn't pass an empty value for setName(). I commented out all the seName() calls and the form ran, but only displayed the elements instantiated in the subclassed form.
My question is this: If I don't use the parent constructor, how do i get and use the parent's form elements?
Solved: Since the constructor was switched to init, the call to the parent also needed to be switched. Easy for someone with php background. Not so much for one who doesn't.
Use
parent::init();
Solved: Since the constructor was switched to init, the call to the parent also needed to be switched. Easy for someone with php background. Not so much for one who doesn't.
Use
parent::init();
You should learn OOP principles first. Obviously you have no understanding of it whatsoever. You need to call parent::init() in you Form_Class::init() method as you wrote, but why? Because otherwise the parent method is not called and is overriden by the From_Class method.
Other thing is that when you have a parent class "SuperForm" with input and submit, then your "SuperForm_Subclass" would have the same elements assigned. There is no need to use "parent::*" to access element (only exception would be if you used static SuperForm variable to store them - which makes no sense).
You can easily use $this->inputElement and $this->submitElement inside your SuperForm_Subclass like you would in the SuperForm class.
In your example you could used the __contruct() as good, but with the same condition of calling the parent constructor. You would be able to access elements generated there too...