SugarCRM Logic Hook Improvements

Edit 1: In response to comments from Jason Eggers I have updated my closure concept to include labels so that they can be identified and uninstalled.

Edit 2: Chad Hutchins further contributed to this concept with a basic outline of a helper class. This post has been updated accordingly.

Like a lot of you SugarCRM dev’s, I find myself creating simple logic hooks fairly often. While this is a simple task I feel that it could be even simpler. Lets look at the current process of creating a logic hook.

1. Create the file /custom/modules/{module}/logic_hooks.php

2. Create your logic hook class at /custom/modules/{module}/logic_hooks_class.php

Two easy steps. That’s all it takes. While this is pretty straight forward I cant help but feel like its an unnecessary amount of work for executing 1 function.

If logic_hooks.php were to support closures (PHP 5.3.0 +) we could achieve all of the above in 1 file (logic_hooks.php) and eliminate the need for the “logic_hooks_class” class all together.

Here is a brief example of how it could potentially work:

In 1 file and roughly 10% of the initial code required we have included all of our logic which makes the logic hook easier to maintain and quicker to write. Personally, this would eliminate at least 75% of my logic hook related files.

Somewhere deeper in the SugarCRM platform this code could be executed with something along the following lines:

To further make using logic hooks more efficient Chad Hutchins has contributed the following helper class concept to make adding and removing logic hooks that much easier.

Thoughts? Opinions? I would love to hear some feedback on this concept!

6 thoughts on “SugarCRM Logic Hook Improvements

  1. I like it. But to avoid collisions with other logic hooks (your own or other 3rd party enhancements) I’d propose doing this via the Ext framework only or in some other logic hook directory where each file represents a single logic hook. This then removes the need for a logic_hooks.php file and the need for logic hook classes.

      • It could be messy installing 3rd party modules using closure-style logic hooks all in a single file. Besides having a pretty decent change in the module installer it can also cause debugging to become a real pain if something were to go wrong. Then there is the issue of removing logic hooks as part a module uninstall.

        • Very valid points. I disagree on the debugging portion of it though. Modern frameworks are using closures left and right and I have yet to have an issue debugging them. That said, the issue of removing module hooks during un-install is something that would indeed need to be addressed. There are ways the closure style hook could be improved to address this. For example, maybe something along the lines of the code in this gist could solve that issue. Thoughts?

          • To help with the install/uninstall issue, there could be a helper class that wraps some of the functionality. Instead of the developers manually stuffing the $hook_array, the helper class would handle the back-end logic. It would have at a minimum these methods:

            // logic


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Current day month ye@r *