Sorry sorry,

Honestly I will get back to you on this one.

I am currently thinking about what you guys have written and at the same time I have a mountain of work I am doing for Xoops.

Another Hourish k?

Catz

@kaotik:

I don't really see an issue either way, this of course depends on the way the hook architecture API is designed in the first place.

If we look at the current framework for the object handler and the XoopsModel particularity, we actually can tell the XoopsModel what database, the table and ID is used when creating an Object.

If we design the API with dual source data in mind, we can easily switch between both methods. I can see a few standard method calls that will able to be used by any module, much as in the same way the XoopsPersistableObjectHandler does at the moment and user hooks could easily be implemented in the same way as the XoopsObjectHandlers do right now.

We could make calls via the hook API in much the same way using $criteria.

I hope this makes sense?

Catz

Quote:

I don't see an issue with modules (that use the object handler) or the even with the core.

Example



Or



Or Even



The bigger problem I see is in modules that might not use the object handler?

Catz

All this sounds excellent but why limit to exchanges between modules ?
A layer for web services could enable modules to "discuss" and will enable modules to be called from the outside.

Interesting opinions. I think valid points for core hooks through a layer have been made.

Right now all of us can access any table in our XOOPS DB and manipulate the data to our requirements ($xoopsDB, $xoopsCriteria, etc), from any module or block (with a little customization). So the question really isn't how to access the data but rather how to get certain functionalities out of modules. Say for example I'm using a shop module. Now for my hompage I want to create a news item specific to each user that shows the status of his/her orders. Through hooks I could accomplish this. The question I am asking is who bears the burden of creating these custom hooks? Would they come included with the modules or would it be up to each developer to create his own custom hooks? I'm just asking because I think it would be easier for the developer to create them.

Another question: Using a service layer/custom hook; would they only perform READ actions or full CRUD capability? There are 2 sides to this argument; one, the data belongs to the developer so he should be allowed to do with it anything he pleases, even if he accidentally 'breaks' modules. The other is that many modules use one to many relationships and need to have Create commands in a certain sequence to maintain DB integrity. Delete and create hooks could easily break those relationships without the developer even realizing it. So should we protect the integrity of the XOOPS install, or give full command to each developer?

Hervet: how would this be implemented? Something like $XoopsHook? Wouldn't that be the idea Catzwolf is already sugesting with $hook = XoopsHook::getInstance();?

I think Zyspec raised an interesting concept, should it be the modules 'pushing' data or the core 'pulling' it from the modules?

Catzwolf: Aren't we risking complicating something that could start off simple? Or should hooks have a certain structure before being implemented? Could we add to it in later releases?

What are your opinions on all of this?

Hello,

Quote:

This is just a quick idea :
$service = XoopsServices::getInstance();

$service->call('mymodule', 'myMethod', 'Credentials', 'myParameter1', 'myParameter2', ...);

For example :


For getting information :
$service->get('mymodule', 'myMethod', 'Credentials', parameters);

Several advantages :
1/ By using a XOOPS layer, XoopsServices, it will enable modules to speak between them and it will enable external "clients" to talk with us (a Java applet, another website etc)
2/ XOOPS itself could use this to communicate with modules. For examples for each module's search

This is just SOAP.

bye,
Hervé

Basically, The whole XOOPS Hook API would just be the gateway to allow you to have a two way communication between two points.

1. Module A to Module B
2. Core C to Module D

Etc etc

You the developer will still have control over you hooks written and what you want the hooks to do and most important how you write them them.

All you are doing is using the API as a method of exchanging information.

As Herve Suggets like I did, this can be used anywhere at any time within your code. You don't just need to limit it as in your original Class and examples, but the system could cycle through pre and post Hook loaders.

Catz

Sounds like a good approach Catz :)
So, what's the next step? I'm afraid I'm not used to SOAP (double pun intended) so this is out of my league.
Anyone else want to express there ideas?

This is my approach for hook system:
http://www.xuups.com/extensions.zip

Extensions is a module that provide hooking system for modules and core and it is based onhttp://fluxbb.org/ extensions code.

It uses xml files for loading extensions.

You can create an extension and upload it to extensions folder or you can access extensions from another site. I'm using xuups.com as a test server for a test extension and you can see it admin after installing this mod.

This can be usefull to patch XOOPS core in case a security issue is found. XOOPS will be able to add an xml file to his updates folder and this way, all sites will be automatically notified and able to install quick fix extension without having to do upload any file.

Core has no hooking points so they must be added in next releases.

You can create a hook just by adding this line in your module or core:


Then extensions can be made to extend this hook points.

Hooks are saved in database and they use cache. Queries are made to database just when you add/delete hooks. When you access a page the hooks are delivered by cached files.

Better is for you to take a look, please read the readme file because you need to make change in include/common.php

Fantastic work, Trabis!!!

This is going to be so useful for any updates, hot fixes, or security alerts!!!

Love it!!!

TIP: whoever install this, you need to read the Readme.txt file There is a change needed in common.php file. Of course, I didn't read it, till Trabis pointed it out to me