Dave224:
Wow! Thank you for taking the time to write such a detailed response. Your tips will be very helpful and are greatly appreciated. Could you please expand your tip on the update function name? Under what conditions should I use "update" and when should I use something else? In your example, you used update followed by a form of the notifier name. Is that on purpose or required, or could I use any name, for example, "my_function"? Could I pass a variable to the next notifier if the name were "update"? Could I pass a variable to other following notifiers, even if they are not next?
Normally, I would prefer to answer questions top down; however, I think that I can address everything along the way but in a different order as I get the feeling by the questions that there is some understanding kicking in and desire to know more.
So, a little understanding about what's going on... On each page load, basically the entire store is "built". There's an initial page load (first visit where a session hasn't begun) and then there is marching through the store or even jumping to one's favorite location. Before the first visit, session data for the anticipated customer doesn't exist or at least in a default store is not yet directly accessible. Once the individual arrives, a session data marker is attempted to be set, and from that point forward, they are basically associated with a session (related to $_SESSION). Now, though when the first and any subsequent page is loaded, basically the index.php file is loaded, which branches out and loads an entire series of logic as well as base code. In that initial load, the includes/auto_loaders folder is accessed as well as other folders such as includes/init_includes (there are many others, but not exactly pertinent to this notifier/observer discussion). As of ZC 1.5.3, part of loading the notifier/observer system is to allow for a file to "independently" serve as an observer (filename is like auto.xxxx.php). Prior to that, an observer had to be referenced/loaded and typically through a config.yyyy.php file found in the includes/auto_loaders directory.
The files in the includes/auto_loaders directory are accessed early enough in the load that the associated files can be mapped to a trigger point or load point. The default for the auto.xxxx.php file is a load point of 180. Anyways, that load point value relates to the sequence at which files/information is loaded. The lower the number the sooner it is loaded. Some things have to be loaded before others. For example to use the function zen_not_null, well the function file has to be loaded to memory. Just like you can't access the $messageStack variable before it is declared/built.
All of this is to say, that the typical generation of an observer is one that is loaded/activated during each page load, and that once the next click is made that basically/generally speaking any information that has been stored in that observer class is wiped to be created/recreated based on the next page load. There are ways around that (ie. $_SESSION, cookie, the database possibly, or if truly necessary written to a file), but the need to get around it depends on the need of the data. If generally just accept that on each page load information will/needs to be created as/where needed then at least won't get hung up on the smaller detail(s). Once something seems functional can consider some memory/time saving techniques.
So to try to answer the question:
Could I pass a variable to other following notifiers, even if they are not next?
Is in essence yes if by not next you still mean that at some point in the current page's load but possibly 1000's of lines of code later with unknown number of notifiers/observers between them, yes they can be "passed" (possibly internally stored to then be retrieved from outside of the current observer or from inside the current observer). If you mean can you store a value inside the observer class during login and on logout expect
Wait, more than one observer? Well yes, there could be two/three/four plugins/programs that all listen to the same code point. How they interact can be beneficial/problematic, the sequence that they load in may be helpful or a hindrance. But, save that thought for later. This is something likely to occur when two or more plugins deal with similar things. For example the notifier you chose to use relates to third party logins... If there were three different places in which to login using a single set of criteria, all of that could happen within a single notifier. But, the data internally stored to the observer class during the login, would not be accessible during the next page load of say logout... (Again there are ways to store data to persist across page loads, but internal to the class that is itself not maintained across page loads, $this->variable, don't work.)
So, regarding the two naming conventions of handling notifiers. The update function is generic and ZC 1.5.1 and before only had an update function and only allowed passing a single non-editable variable. The variable could be an array, but any changes made to it stay only in the observer class. As of the production release of ZC 1.5.3, 9 additional variables have become available where each of those variables could be used, edited, and the changes returned to the original function. They don't have to be edited, but they can be. In adding this feature, the Zen Cart developers decided that they would also expand the operation a little. So, they created the possibility for a function to be called that follows the naming convention update+Camelized Notifier, you can look up what camelize means, but basically it removes the underscores and then capitalizes the first character that follows it leaving the remaining characters lower-case. Fortunately for now, PHP doesn't distinguish between capitalization of functions, but does for variables. (ie: $db->Execute($sql); will perform the same as $db->execute($sql); for now...) No telling when the PHP group may go to even more stringent coding expectations and require function capitalization to be consistent between declaration and use.
Anyways, so you have two options, you can use the new method of updateCamelCase(....) or update(....). This naming convention is governed by code within the ZC system. If you wanted to have a my_func() type function, it would have to be called by some other code which could reside in the update() function. You can even have both functions updateCamelCase() and update() in the same observer class, but the way the code is written it will attempt to execute the camel case version first if found, if not found then attempt to execute the update function.
So, which is "better"? That really depends. I do know, that if your code is written using the update function only and default values are not set (update(&$class, $notifier, $arraylike, &$firstvalue, &$secondvalue)), and the code is installed to a vanilla install of ZC 1.5.1 or before, then the store will break. This is because in the earlier versions, they didn't know/recognize that there could be other variables, and therefore don't send a default, and then PHP says "HEY! YOU DIDN'T SET A VALUE AND NOW I DON'T KNOW WHAT TO DO!!!".
If you use the update version and you are observing more than one notifier, then within the update function you would want (maybe) to see what notifier was used to get into the update code so that action A is taken for notifier 1 but action B is taken for notifier 2... If they both have some common action, then the update function may be preferred. Otherwise, if they do different things, it may be desirable to use the camelcase version. I look at it as the code checks for the existence of the camelcase first, so why not use it? Also, the variables being received can be tailored to what they are rather than some generic $var1, $var2, $var3, etc... This improves code readability and can simplify operations. From that/there you can have other functions that are called from either. But this aspect is more about design, intent, and need.
As to the passing of variables, again, if the class is used in a single load sequence (like using both notifiers identified before), then if you use the camel case version, you'll need to store data internally when reaching the first notifier to be used by the second camelcase function (or update function if the camelcase function doesn't exist). If you just use the update function, then if you make the variable to be kept static it will persist, but otherwise will disappear when the second notifier is reached because the update function will basically be called again for the first time. (a bit of an oxymoron, I know)
