views:

79

answers:

2

** New EDIT **

so what I'm trying to do is this.

I want the to add new form elements generated by my module on the product view of the following url

http://magento.example.com/catalog/product/view/id/46

ultimately these elements will be determined to show up by a related table in my module

I expected that if I extended Mage_Catalog_Block_Product_View in my module as shown below I would be able to create a block in the product form that would contain such form fields, only if he are in the related table in my module

so I created a test.phtml file in

 app/design/frontend/default/default/templates/<module>/test.phtml

then as you can see in my the View.php file described bellow I built the block and displayed it in the product view.

It did appear but 5 times too many. from the answers below this is normal so that answers the question as to why the it shows up five times but leaves the question what is the proper way to proceecd since this plan is not going to work

** End New Edit **

in my module I call _prepareLayout() and it does this 5 times when i pull up the page

here's my code in

/app/code/local/Namespace/Module/Product/Veiw.php
class <Namespace>_<module>_Block_Product_View extends Mage_Catalog_Block_Product_View {
    protected function _toHtml() {
        return parent::_toHtml();
    }

    public function _prepareLayout() {
        $block = $this->getLayout()->createBlock(
            'Mage_Core_Block_Template',
            'my_block_name_here',
            array('template' => '<module>/test.phtml')
        );
        if ($block){
            $this->getLayout()->getBlock('content')->insert($block)->toHtml();
        }else{
            echo "no block";
        }
            return parent::_prepareLayout();
    }
}

NOTE: I just noticed this also takes away the price availability qty and add to cart button. which is also a problem

EDIT First I want to thank you all for your answers. Second i want to give you more context

the reason for choosing to do this in the module is that I don't want the block to show up on every product . What i have is a table of what I'll call custom options containing properties of the product sort of like hair color height weight etc and depending on what set of properties are attached to the product (if any) will depend on what html content will show up on the page. so in one case it my get a drop down menu and in another case it may get an input box. the other very important piece is that this must be setup so that I can give the end result out as a module that can be installed and not worrry that it won't show up if someone upgrades there magento

that said does it still make sense to do this all in the xml file ?

+2  A: 

I took a look at a stock Magento install of CE 1.4.1, and unmodified the _prepareLayout method is called six times when loading the URL

http://magento.example.com/catalog/product/view/id/46

That's because the class is instantiated six times. So that's the correct behavior.

As for the vanishing element, I can'y say for sure, but your override to _prepareLayout doesn't appear to either

  1. Do the same things as Mage_Catalog_Block_Product_View::_prepareLayout

  2. Call parent::_prepareLayout();

When you override a class in a Magento you're replacing an existing class with your own. If you change a method, you're responsible for that old code being run.

It's not clear what you're trying to accomplish here. You should consider breaking your problem down into smaller problems, and then posting one (or more) "I tried X, expected Y, and got Z" type questions. As written no one's going to be able to answer your question.

Alan Storm
@Alan Storm this is indeed the page that I'm trying to modify. I did leave out the return parent::_prepareLayout(); in my post but do have it in my original code so I guess the question is how to I call the phtml file with out using prepare layout since prepare layout is called 5 times
mcgrailm
I knwo you think you're telling us what you need to know when you say 'call the phtml file', but that could mean so many different things. Last Time: Describe what you're trying to do, describe the approach you're taking, describe what you expect to happen vs. what is actually happening.
Alan Storm
+1  A: 

It seems to me that your code is overriding a core Magento module in order to achieve what could be easily done in the layout xml configuration. I would strongly recommend the follwing:

  1. Use the built-in configuration mechanisms (e.g. layout xml - read Alan's excellent tutorial here) instead of writing code whenever possible.
  2. Don't override the core code
  3. if you must change the behaviour of the core code, use an Observer rather than Rewrite/Override
  4. if you absolutely must Override, always call parent::whatever()

For example, if you create a <module>.xml layout file in your theme (app/design/frontend/default/<theme>/layout), you could use the following code:

<catalog_product_view>
    <reference name="content">
        <block type="module/block" name"my_block_name_here" template="module/test.phtml"/>
    </reference>
</catalog_product_view>

You would then need to use a getChildHtml('my_block_name_here'); call within your phtml to position the block.

So unless there is other functionality happening inside your _prepareLayout, there's no need to override the core, or even to override the default catalog.xml.

EDIT (small edit above)

So now in your Block (I would recommend that you call it Namespace_Module_Block_Product_Customattributes or something like that), you are not overriding the core Product_View block, but merely processing your logic for what html widgets to use to render your custom attributes. Leave the rest of the tier prices, add to cart, other generic product block code, etc to Magento to work out.

If you are worried about the upgrade path for your module's users, you should definitely NOT be overriding core code. Use the configuration approach and very selectively introduce code that "plays nice" with the system rather than try to boss it around with overrides.

Jonathan Day
@Jonathan Day thank you for your answer. Please see my edit above
mcgrailm
@mcgrailm - yes, it still makes sense to call the Block in your layout xml. The logic as to whether to display a drop-down or radio button will be processed by your custom Block. See my edit above.
Jonathan Day