PHP question on /includes/templates/mytemplate/templates/tpl_product_info_display.php

[lhungil]

Not sure if this is the right forum for php questions, but I'm having trouble finding a PHP forum

I'm trying to display the manufacturers image on the product info page which when clicked goes to their url to see all that manufacturers products ...

*** deleted ***
Almost identical to the second snippet posted by mc12345678. Only difference was the use of an observer to retrieve the manufacturer info (in a single SQL query) instead of retrieving directly in the template.
*** deleted ***

Yes, I am aware that there is a subtle difference between == and ===

Just curious, it a known fact about 'unwanted consequences' , or is it the same disclaimer that I probably should have made on the basis that it probably hasn't been tested in every possible case? ...

As far as I know, unwanted consequences are likely when the original author of the code WANTED the behavior of ==, not ===. When upgrading old code, the author of the old code may have knowingly relied upon: false == 0 == "0" == null == "" (so just changing to === could have negative consequences). Or the old code may be comparing objects (not primitives) and thus intentionally using == instead of ===.


For primitive types in PHP (such as int, float, bool, etc) I'm usually a fan of using === (aka the identity operator or identical) in favor of == (aka the comparison operator or equals). IMHO this makes it less likely for a coder skimming over code to misinterpret the intent (and helps the coder avoid mistakes if they forget how == works in PHP).


When it comes to objects in PHP, I disagree with using == (aka the comparison operator or equals) altogether in favor of the class defining a comparison method (more control over what constitutes equality - such as the use of === for checking primitive properties and checking the actual classname). For objects, === (aka the identity operator or identical) is not often used as it only evaluates true when the two objects are the same instance of the same class.

[mc12345678]

*** deleted ***
Almost identical to the second snippet posted by mc12345678. Only difference was the use of an observer to retrieve the manufacturer info (in a single SQL query) instead of retrieving directly in the template.
*** deleted ***

So curious, in the concept of using the observer, that would still require modification to the template file correct? (Ie. One issue with the modification proposed is that in subsequent upgrades or in new templates, this change must be carried over to remain a part of the displayed informatiion.) I haven't played/tested this aspect but do the variables assigned in the observer become a part ofthe global space or do they fall out of scope? Would declaring the variable in the observer as global maintain it in scope for "global" use?

I understand that the above basically would have provided all of the requested data (manufacturers_id as well as manufacturers_image), but was trying to understand how to keep it in use for the code space that had the notifier.

[lhungil]

Only three reasons I was initially thinking observer on this one. First it removes data querying and business logic from the presentation layer (strong reason in my little world). Second only one SQL query is needed versus one per zen_get_products_manufacturers_* function call (weaker reason in my little world as most SQL queries are very fast). Third, it provides yet another example of how to use an observer.

So curious, in the concept of using the observer, that would still require modification to the template file correct? ...

Yes, the exact same ones as you already provided while I was typing (just using a variable in place of the zen_get_products_manufacturers_* function calls).

... Would declaring the variable in the observer as global maintain it in scope for "global" use? ...

Yes.

Declaring the variable as in the global scope (and making it available) inside a method (class function) works.

global $my_special_variable;

Assigning and accessing the variable using $GLOBAL in the observer also works.

$GLOBALS['my_special_variable']

[mc12345678]

Only three reasons I was initially thinking observer on this one. First it removes data querying and business logic from the presentation layer (strong reason in my little world). Second only one SQL query is needed versus one per zen_get_products_manufacturers_* function call (weaker reason in my little world as most SQL queries are very fast). Third, it provides yet another example of how to use an observer.



Yes, the exact same ones as you already provided while I was typing (just using a variable in place of the zen_get_products_manufacturers_* function calls).


Yes.

Declaring the variable as in the global scope (and making it available) inside a method (class function) works.

global $my_special_variable;

Assigning and accessing the variable using $GLOBAL in the observer also works.

$GLOBALS['my_special_variable']

Come to think about it, I may have misspoke about not having considered passing a variable back to the main program flow by declaring it global within the observer. I think it was an "issue" of passing a variable back to a function without modifying the function where the notifier (in ZC 1.5.4+) did not include the variable as a pointer and the variable is not associated with the class...

Sort of on a related/non-related subject and probably should start a new thread in the ZC suggestion area, but a proposed solution to this issue made me think about it... The use of the "procedure" names in the observer files is one that doesn't lend itself well to consistent file search. To explain, the observer functions when listening to/for a notifier are either:
function update
with an if statement to identify the notifier inside of the update function
or
function updateNotifierName (without need for capital letters and only available beginning in ZC 1.5.4)

The notifier is of the type 'NOTIFIER_NAME' but when troubleshooting code, if a value changed from just before a notifier to just after the notifier, one could not "readily" find the code that caused the change just by using NOTIFIER_NAME in the developers toolkit if the function type naming added in ZC 1.5.4 were used. Personally I add the notifier name in a comment before the listing, but that is because of what I describe above. Suggestion is that this (I think highly helpful feature) use/allow a naming convention to include the underlines at least in the NOTIFIER_NAME variable and am non-committal to the need of it between update and NOTIFIER_NAME.