Is there a standardized way to get contents from other modules?

PostNuke had some functions called "hooks" that handled inter-modules requests for read/list/add/del/mod contents.
It was very easy to setup modules for newspaper-like section pages, advanced categories systems and so on.

I need to port some of those modules I wrote to Xoops... but I can't understand how should I do it...
I don't want to hardcode sql queries or call internal functions of the modules to keep a good layer of stability throughout versions...

The idea is very good, but I have had several people looking at PostNuke and especially the Hook thingie was letting them down. Very hard to see, how it works, was the feedback from them.

At present XOOPS does not have that kind of interaction between modules, but if you have a good idea as to how such a feature could be implemented, don't hesitate to bring it up. Not necessarily in code, but just in general terms with database tables, function naming etc.

I have an idear about how it could be implemented.
Each module should provide it's own interface to its't database and perhaps even it's display functions.
During install, this code should be registrated or collected into some central XOOPS file. With every new module installed, the registration or file should be rebuild.
The interface should be maintained in a backward compatible manner, and always provide a version-string, so it's possible to check if the functionality one needs is implemented in the currently installed modules.
The modules relying on functionality from modules not installed, or modules not new enough to contain the functionality needed, should complain in a standardized fasion (instead of just crashing!).

The basic functionality could be based over a getContents('modulename.DataSet'), and a getDisplayContents('modulename.DataSet') function. The first should return a raw array of data, the second should return html formatted data.
The modulename.DataSet could be taken from a list in the database, which each has a link to the php code from various installed modules which support this functionality. Some modulename.DataSet should be reserved, such as version strings etc.

Regards,
Daigoro

Not that I know much about XOOPs programming etc, but I think if you haven't seen this threadcloning modules then it might be of interest.

Although it started as how do i clone a module, it's turning into much more. I invite you to connect with Phatjew, because he is working on cloning and much more.

krayc

I've read the thread, the vision of phatjew is just what I've been looking for, One module to display content of various other modules, so a kind of meta index.
Good luck Phatjew

I suspect the key to this development is really understanding and implementing the smarty core. A very useful notion Fabrizio and good luck with your R&D

Richard

Quote:
Daigoro, you are right. That's more or less the same approach Postnuke used.
If someone wants to know more, there is a document on hooks in Postnuke

Some more...

Every module should register all the functions it can provide.
We can define some of them as mandatory to assure a minimum layer of use and integration (getVersion, getItem, getProvidedFunctions...let's think about them...)

Every module MUST assure that it doesn't need any other module to successfully execute those functions (or, otherwise, there must be a way to know that it will fail...and discover loops!)

"Hooks" system will be provided in php code AND in smarty functions, to assure intermodule operation (in particular for raw access to the content) and for easy templating (formatted HTML Smary-tagged content, registered via $smarty->register_object() function)

We must be careful about how to call modules function, because we don't want different modules loaded at the same time with conflicting namespaces.
I will post more informations about how PN solved this problem...

Ok, enough for now to write about... I'll post more info later.

Ok, I wrote a XoopsHook class, a test "Newspaper" module and I am making some tests with a copy of the News Module... but I'm really getting mad and I need help!

What are the *real* classes?? the ones in /kernel or the ones in /class ??? I saw some of them called in both the directories... and a lot of them have also the same names!
(XoopsBlock in kernel/block.php and class/xoopsblock.php).

They have different methods and variables!!

Please let me know how to go on...

I believe that the kernel/*.* is the right place to look, when encountering doublets.

My guess is that class/xoopsblock.php is kept for backwards compatibility... but I do not know for sure.