Skip to main content
Topic: Hooks "standardization" (Read 7924 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Hooks "standardization"

This morning I wake up and started thinking a bit (baaaad thing!!).

A couple of days ago I discovered that a standard install of memcached cannot cache "things" bigger than 1 MB.
With the current way hooks are set up I have the feeling the modSettings array would reach that size rather easily and then not be cached any more.

So, what I was thinking is: instead of allowing define functions and files includes, etc., why don't we use a simpler approach: in the db we store (for each hook the mod wants) a "prefix", that is then used both to load a file in the form prefix.integration.php and to call the function prefix_integration_name_of_the_hook.

In other words, a bit of standardization.

Opinions?
Bugs creator.
Features destroyer.
Template killer.

Re: Hooks "standardization"

Reply #1

Could you give an example of what you are trying to do?  Is that just to save space in the settings table?  Could we move the hooks to their own table instead or would that be part of the change?

The thing is with the hooks, whatever we have we need to be happy with since changing that again in the future is not great for anyone.

Re: Hooks "standardization"

Reply #2

Quote from: Spuds – Could you give an example of what you are trying to do?

What I was thinking was something like that:
Code: [Select]
function call_integration_hook($hook, $parameters = array())
{
 global $modSettings, $settings, $db_show_debug, $context;
 static $loaded_files = array();

 if ($db_show_debug === true)
 $context['debug']['hooks'][] = $hook;

 $results = array();
 if (empty($modSettings[$hook]))
 return $results;

 $prefixes = explode(',', $modSettings[$hook]);
 // Loop through each function.
 foreach ($prefixes as $prefix)
 {
 $prefix = trim($prefix);
 if (!in_array($prefix, $loaded_files) && file_exists(SUBSDIR . '/' . strtr($prefix, '::', '_') . '.integration.php'))
 {
 require_once(SUBSDIR . '/' . strtr($prefix, '::', '_') . '.integration.php');
 $loaded_files[] = $prefix;
 }

 if (strpos($prefix, '::') !== false)
 {
 $call = explode('::', $prefix);
 $call[1] = $call[1] . '_' . $hook;
 }
 else
 $call = $prefix . '_' . $hook;

 // Is it valid?
 if (is_callable($call))
 $results[$function] = call_user_func_array($call, $parameters);
 }

 return $results;
}

So, instead of for example adding a hook like:
Code: [Select]
		<hook hook="integrate_theme_include" file="LANGUAGEDIR/SPortal.english.php" />
<hook hook="integrate_load_theme" function="sportal_init" file="SOURCEDIR/Portal.subs.php" />
<hook hook="integrate_actions" function="sp_integrate_actions" file="SOURCEDIR/PortalIntegration.subs.php" />
<hook hook="integrate_admin_areas" function="sp_integrate_admin_areas" file="SOURCEDIR/PortalIntegration.subs.php"/>
<hook hook="integrate_load_permissions" function="sp_integrate_load_permissions" file="SOURCEDIR/PortalIntegration.subs.php"/>
<hook hook="integrate_whos_online" function="sp_integrate_whos_online" file="SOURCEDIR/PortalIntegration.subs.php"/>
<hook hook="integrate_frontpage" function="sp_integrate_frontpage" file="SOURCEDIR/PortalIntegration.subs.php"/>
<hook hook="integrate_quickhelp" function="sp_integrate_quickhelp" file="SOURCEDIR/PortalIntegration.subs.php"/>
<hook hook="integrate_buffer" function="sp_integrate_exit" file="SOURCEDIR/PortalIntegration.subs.php"/>
<hook hook="integrate_menu_buttons" function="sp_integrate_menu_buttons" file="SOURCEDIR/PortalIntegration.subs.php"/>
it would be:
Code: [Select]
 <hook hook="integrate_theme_include" function="sportal" />
 <hook hook="integrate_load_theme" function="sportal" />
 <hook hook="integrate_actions" function="sportal" />
 <hook hook="integrate_admin_areas" function="sportal" />
 <hook hook="integrate_load_permissions" function="sportal" />
 <hook hook="integrate_whos_online" function="sportal" />
 <hook hook="integrate_frontpage" function="sportal" />
 <hook hook="integrate_quickhelp" function="sportal" />
 <hook hook="integrate_buffer" function="sportal" />
 <hook hook="integrate_menu_buttons" function="sportal" />

That at some point may even be changed to:
Code: [Select]
 <hook prefix="sportal" hook="integrate_theme_include,integrate_load_theme,integrate_actions,integrate_admin_areas,integrate_load_permissions,integrate_whos_online,integrate_frontpage,integrate_quickhelp,integrate_buffer,integrate_menu_buttons" />

And sportal.integration.php would have the functions:
Code: [Select]
function sportal_integrate_theme_include()
{
}

function sportal_integrate_load_theme()
{
}

function sportal_integrate_actions()
{
}
etc.

Quote from: Spuds – Is that just to save space in the settings table?
...mmm...no, not really... :P
It's also because we already accepted some naming conventions (i.e. dispatcher), so I was wondering if it is worth to have some naming conventions here too.

Dunno if it is worth to do now, or even in general.

Quote from: Spuds – Could we move the hooks to their own table instead or would that be part of the change?
Yep, we could do that too.

Quote from: Spuds – The thing is with the hooks, whatever we have we need to be happy with since changing that again in the future is not great for anyone.
Yep, I know...
I don't expect to have them stable "forever", but at least for a good period of time.
Bugs creator.
Features destroyer.
Template killer.

Re: Hooks "standardization"

Reply #3

Personally I'd drop all the integrate_ prefixes. They've long since transcended their 'integration' purpose into more generic callback/listeners.

What I did in Wedge might be relevant too, I had it set up so that a given plugin would declare its hooks and they would be pushed into their own element inside $modSettings, which would give you the namespacing you're hinting at. Then you only need to keep what's necessary for loading; the hook to be used, the file/function to call, call priority if you're doing that.

If you go down the road of having a library and a class autoloader, like XenForo does, you don't even need to worry about file/path, you just have the class name be declared and the hook can instantiate it as necessary.

If you want to save a little more space, don't get into using serialize() as much in the table, use json_encode() because it's smaller (though requires being UTF-8 only for reliability)

Re: Hooks "standardization"

Reply #4

Yep, have a simple "entry point" is something I was considering too since a while, but I didn't spent much time thinking about it... :P

Probably 1.0 is too early for an autoloader, but decisions on the matter are way out of my league. :P
Bugs creator.
Features destroyer.
Template killer.

Re: Hooks "standardization"

Reply #5

Code: [Select]
<hook hook="
no good

can better yaml format?
Code: [Select]
hooks:
    - { name: integrate_load_theme, file: SOURCEDIR/Portal.subs.php, func: sportal_init }
    - { name: integrate_whos_online, file: SOURCEDIR/PortalIntegration.subs.php, func: sp_integrate_whos_online }




Last Edit: September 28, 2013, 05:22:59 am by Inter
Sorry for my English

Re: Hooks "standardization"

Reply #6

Never use YAML, it's stupid.
LiveGallery - Simple gallery addon for ElkArte

Re: Hooks "standardization"

Reply #7

Another advantage of something like this, would be we can know which hook/s belong to which mod, for example to simply shut it down with one action instead of rely on the mod itself (or for example to group the hooks in the report page by mod).

Yes, a separated table would allow that too. :P

I tend to have a similar reaction to YAML... I never used it, so I may be badly wrong.
Bugs creator.
Features destroyer.
Template killer.

Re: Hooks "standardization"

Reply #8

If you do it that way, you can do things like disabling all the hooks if the folder in which a plugin exists is not present ;)

Re: Hooks "standardization"

Reply #9

In order to work with YAML files we'd neeed a YAML parser class. There's a YAML PECL extension available, however it's not part of the default php installation. Thus we'd have to maintain our own YAML class or pick an open library..
Thorsten "TE" Eurich
------------------------

Re: Hooks "standardization"

Reply #10

I was thinking: the log_packages is already a table that can be used for hooks, at least the way I'm describing them here in this topic: maybe there would be a bit of data redundancy, though it already holds the db changes and anyway the table shouldn't grow that big.
Bugs creator.
Features destroyer.
Template killer.

Re: Hooks "standardization"

Reply #11

Don't forget that the string can be compressed. So a 1MB string could be much smaller. Even still, if it is 1 MB of string for hook registration, I think that might be a sign of a bigger problem. Just to note, this is probably way premature optimization, unless you've seen people with this issue.

Oh, and definitely remove the "integrate_" portion.

Re: Hooks "standardization"

Reply #12

 emanuele still have to start here...
I wanted to crush the "positioning", then I have another thing to work on and then...okay, this will probably go into 1.1/2.0 (with backward compat so nobody will have problems :P).
Bugs creator.
Features destroyer.
Template killer.