XOOPS 
Forum
Forum Index General Forums Community Support Modules Support Themes Support Development International Support Module Hack Reviews Theme Designer Talk
  1. Board index / 
  2. Xoops Development / 
  3. Xoops Development 
  4.  / Hook system for Xoops
Register
1
kaotik
Hook system for Xoops

  • 2009/3/19 14:05

  • kaotik

  • Just can't stay away

  • Posts: 861

  • Since: 2004/2/19


This is a simple hook system I developed for xoops. It uses a new class called hook. This is what it does:
First it searches for all active modules.
Then it tries to a load a hook file from each module.
You can then use the functions contained in each hook file for your own module.
I have also included 2 test modules that exemplify how it works.
I did it this way so that module developers can have maximum liberty to customize their own hooks.
xoops hook system
www.kaotik.biz
2
Catzwolf
Re: Hook system for Xoops

  • 2009/3/19 15:05

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


Nice little class,

And I think that something like this could be extended in to something a little bigger.

Maybe we could expand it to allow direct calls to the module hook like

xoops_load('hook');
$hook = XoopsHook::getInstance();

$object = $hook->get( 'moduledir', 'methodname', $critera = array() );

Just like with the install, update and uninstall function, there could be unified function to allow us to get say items from any module table directly into your own module or away to import from your own module into say news.

What you think?

Catz
3
dbman
Re: Hook system for Xoops

  • 2009/3/19 15:22

  • dbman

  • Friend of XOOPS

  • Posts: 172

  • Since: 2005/4/28


Nice work Kaotik! I have been doing this retrieving data directly from other modules tables using my own methods. Hooked access to the modules functions is much cleaner. A future core implementation perhaps?
4
Catzwolf
Re: Hook system for Xoops

  • 2009/3/19 15:29

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


Quote:

Nice work Kaotik! I have been doing this retrieving data directly from other modules tables using my own methods.


How does yours differ from Kaotiks and would it be possible to see a working copy from you on this dbman?

Quote:

Hooked access to the modules functions is much cleaner. A future core implementation perhaps?


I can't speak for everyone on the core and I am not sure 100% what is happening with v3.0 yet (feature wise), but if it is not already there then we could use this basis as a start for future versions.

Catz
5
zyspec
Re: Hook system for Xoops

  • 2009/3/19 15:46

  • zyspec

  • Module Developer

  • Posts: 1095

  • Since: 2004/9/21


Catz - I agree. A method similar to the install/unistall function would be a clean way to implement this. This should allow a mod dev to create a "services" module without creating a "stand alone" module - say a shipping module, a payment gateway, etc.

The ability to "push" data to other modules (like news or a calendar) could really add to the module dev's ability to provide a more MVC type implementation.

dbman - is there anything in the interface Catzwolf outlined above that wouldn't meet the needs of what you've done in the past?
6
kaotik
Re: Hook system for Xoops

  • 2009/3/19 16:51

  • kaotik

  • Just can't stay away

  • Posts: 861

  • Since: 2004/2/19


Hi all
Catzwolf: I actually thought about a more elaborate method, but (imho) there are 2 ways of seeing this:
1- The hook is an integral part of the module, as such the module developer creates the hooks. Users can always customize them of course. One advantage of this is that, since the module creator knows every intricacy to his/her module, it's a lot easier for him to create these hooks.
2- The module data belongs to the site, as such should be accessed by the site, from any module. In theory this sounds like the better method but there are some drawbacks; what if data from the module isn't stored solely in DB? I've designed modules where part of the data is stored in an xml file. There's also the question of system resources, hooks, if not designed very carefully can bring a site with a lot of modules to it's knees.
My solution uses method 1.
Could there be a solution that uses the best of both methods?
www.kaotik.biz
7
dbman
Re: Hook system for Xoops

  • 2009/3/19 18:32

  • dbman

  • Friend of XOOPS

  • Posts: 172

  • Since: 2005/4/28


The hook class in general would save me a ton of work. @zyspec: Catz's suggestions would exceed my current implementation processes and allow a more generic approach to data read/write operations.

Currently I use XOOPS as an extension or library for other applications created for our organization.

As an example lets assume some event in our internal application requires a news article be posted to our XOOPS website via a specific trigger like a form submission. Within our form handler method I include functionality to write data to the news module tables incorporating data captured in our form submission to populate the news tables where applicable. Inversely our end-users may be submitting items to modules within our XOOPS site that we use within our internal app. The required functionality for XOOPS module data is included in our data access methods or into our applications data model.

With the hook class I would likely convert our internal applications to modules and use XOOPS more like a framework then a library :) I like the services concept as well, in a way that probably best describes what I do now.

As kaotik mentions it would be nice and probably necessary to extend hooking to resources other then database tables. There are many possibilities for module plugins and application bridging using hooks.

8
kaotik
Re: Hook system for Xoops

  • 2009/3/19 20:33

  • kaotik

  • Just can't stay away

  • Posts: 861

  • Since: 2004/2/19


dbman: taking your idea further, so a hook would basically be an access mechanism to modules tables? If so then the hooks would be in the core and not modules?
The ideas aren't mutually exclusive, we could have both systems (like notification also has 2 ways of viewing), modules could come with their own hooks or a developer could use core hooks:
xoops_load('hook');
$hook = XoopsHook::getInstance();
$object = $hook->get( 'moduledir', 'methodname', $critera = array() );

This would give total freedom to both module developers and end users seeking to customize.
What do you think?
www.kaotik.biz
9
kaotik
Re: Hook system for Xoops

  • 2009/3/19 21:00

  • kaotik

  • Just can't stay away

  • Posts: 861

  • Since: 2004/2/19


Catzwolf: what´s your opinion on this?
www.kaotik.biz
10
dbman
Re: Hook system for Xoops

  • 2009/3/19 21:13

  • dbman

  • Friend of XOOPS

  • Posts: 172

  • Since: 2005/4/28


There are arguments for/against either approach. My implementation I suspect is very rare.

I would think it depends on the complexity of the modules involved. The core only approach may be useful for modules that bridge other applications (WordPress, MediaWiki, etc). Also would be useful for mature modules which are no longer in development. If the core hook could encompass the system tables (users, configuration, etc) this would open many possibilities.

On the other hand I am sure there are modules with complex data structures, non-database related resources and cascading read/write functionality which may make a module hook a better choice.

Future developments in the core and legacy modules make it tough to say yes or no either way. I encourage other developers to add their 2 cents. For me this is an exciting topic :)
(1) 2 3 »

Login

Register now!  |  Lost Password?

Search

Advanced Search

Recent Posts

Who's Online

157 user(s) are online (99 user(s) are browsing Support Forums)

Members: 0

Guests: 157

more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits