Florian Lagg wrote: > >> 3) Hooks need data and (maybe) return modified data. >> Therefore I suggest to >> pack all data of a plugin-hook into a single argument which >> is an array (or object). The plugin method then returns the >> complete array (object) with modified data. > > Yes, some hooks may need data. I personally prefer objects rather than > arrays. I dont know if there is an object for any kind of data. If not we > have to write them too.
We could use stdClass to create any kind of objects. But objects are always passed as reference. This is good for the memory but dangerous for the application code. If passed by reference a plugin can (accidentally) change data in the argument object. Arrays are passed by value (but only copied on change). If a plugin changes some argument values it does not affect the original data. The plugin has to return the new data and even then the application can decide whether to use the changed data or not. With arrays we can have "read-only" arguments, with objects we don't. > I think we have three types of hooks: (+ two special types) Hooks should always get one argument (could be null) which is an array. In case of the address book we have the rcube_result_set class which is some sort of an iterator for "data rows" or records. > How should we handle different types of hooks? > I think we shall not use 1. (see reason above) > The 2nd one is easy and most used. > For the 3rd we have multiple options: > * Call the plugin method for each object > * Call the plugin once with an array of objects > * (my favourite) let the plugin decide how to call the method on hook > registry. For some plugins it could be essential to handle all hooks at > once. Calling the hook only once for an event - even if there are multiple records affected - is slightly more effective. If we pass a result_set object the plugin can still process each record. > > After calling a hook we should take the returning object and write it back > to the original sources, right? It depends on the implementation. The core application should have control of what data can be changed by a plugin and not the plugin itself. > > Ah... btw: > I prefer the naming convention > 'user-login-after' instead of your 'after-login' > for hook names because it groups things together. I havn't seen rules on > this in the guidelines, is there any? > It just groups together what should be togehter. > Any hook on user begin with..: user > Any hook on login begins with: user_login > The hook after a login uses..: user_login_after > Is this OK? (I chaged the dash with underline too meet the guidelines) That's OK. Since hooks are not directly related to object methods but simple strings we're not bound to the guidelines here. Using dashes could help distinguish between hooks and method names... ~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
