kaotik,

I think we should allow CRUD provided it's done using a defined method. If we use a PHP5 interface to define what's required and then let the module developer create the class and methods using the interface then each module developer can control read/write access to the tables to ensure it's done correctly while at the same time giving a uniform set of methods that can be counted on from module-to-module.

We may want to extend it futher so that specific types of modules (say all calendars or all photo galleries) also include additional 'standard' methods for that type of module.

Thanks Mamba, I did change again the readme file to change the include method, because it was giving blank page.

Anyway, this is not like the idea discussed above. It is a little more simple and I think it is more powerfull because the developer can inject the code he wants in any available hook just like if it was typing there! This means that we do not need to worry with variable scope.

Just need to add encryption to the cache files because we don't want a hacker to make changes there and compromise the hooks

This is not fully functional yet, it is just a base where we could work on.
Thanks!

trabis,

Interesting concept. I plan to look at it when I get some time. I have to admit that on the surface it sounds 'dangerous'. I worked through something like this with a big software company in the past and it took some real effort to ensure that any hooks loaded from 'another server' weren't spoofed and didn't break anything.

Many corporations won't want to load hooks even from a local server "automatically". They want to make sure they explicitly approve and review any changes to the system before it's completed. This is to address both security and compatibility.

Quote:

Yes it looks. You can install an extension that just deletes your site. But thinking about it, you can have the same when installing a module.

We can have the option of having external sites feeding extensions. XOOPS can deliver fixes, but a mod developer could also provide fixes or extra functions.
We can maintain a xml with banned ips for using in protector for example!
But this process needs to be secured with encryption just to be sure that what you ask is what you get.
Then you are free to choose your providers or not having providers at all.

This xml files provide snippets of code so, they are not much powerful. Extensions that are uploaded by ftp are the most important. You can add an extension that will just add an include statement on a hook. That way you can trigger anything with your included file and you don´t have to write the code in the xml.

Extensions can be used to include jquery library for example.

They can be used to add extra field on a database.
Extensions have an install and uninstall method so they can drop the added fields when uninstaled!

There is plenty of fish here.

your concept seems interesting although, if the point is to add hooks, aren't extensions superfluous? In other words, aren't extensions the same thing as modules but with a different name?

Diference:
- Extensions are executed in every page load, modules are not. - Extensions need to use hook points to be executed, modules/core are supposed to create these hooks, not using them.

Protector module can not make use of hook points at the begining and ending of common.php without having the protector extension installed.

Defacer module cannot make use of hook point in header.php and footer.php without having the defacer extension installed.

A jQuery extension can make use of hook point in footer.php without need of having a jQuery module.

I hope you understood the concept.

Here are some thoughts....

To minimize collision of simular "hooks" I think we also need a way to register the hooks as well as verify they are there.

The problem I see with how we are discussing things now is that you could still have a number of simular functions in place. Unless a module knows another module of set version is installed the module can't assume there is the necissary hook for it..

We should shoot to only do this at module install/upgrade/remove stage which should not impact actual rendering of the site to the users.

We should also have a way for modules to know when there is another module depending on it being there so you know if you should delete it or not...

I would think the purpose of having hooks should be to reduce the amount of code we have in place as well as make it easier to produce new modules.

I believe we should head towards a goal to produce a method of registering these hooks. We establish a supported list of hooks and definitions of what the intended definition of them is. Then it is up to the developers to write hooks compatible with this standard definition thus allowing other modules to know if they use this hook they know what to expect.

With little known or non standard hooks the hooks should be documented so that others can use them.

To support future versions of XOOPS and the needs of those I think we need a way to register the hook versions as well. With any additions to the hook listed in the "version".

So lets say we have a class definition that is made to add a new user to the system.. We have version 1.0 which is compatible with 2.3.3 of xoops. All we need to do is provide the user name, password and email address and it does the rest..


Normally we might use the Profile module to do this... Well we have a new module we want to use instead... It is also compatible with "newuser 1.0" but has additional functionality. We might even now have a "new user 2.0" if there is enough call for it.

So now we have another module that requires "new user 1.0"... It can use either the "profile" module or this second module and know it will have a compatible "new user" add.. The version 2.0 would have to maintain downward compatibility with version 1.0 so other modules requiring 1.0 would know that they would still work no matter if we had version 2.0 or 3.0... But if you installed newer modules that needed the 2.0 they would need the newer module... To promote universal hooks these hooks should only have the defined items included inside it.

The intention here is then we have a simular system to the system API but can be changed on the fly as necissary. You should still be able to have custom hooks as well but as we develop much used hooks we should define them and perhaps get to having a library of hooks that are seperate from the modules that are loaded as needed. Make sense?

Rodney

Another power of registering the hooks is that you can cascade them if you keep track of the one that is supposed to be run.

As an example...
Module A B and C all have user Delete hooks..

You want all 3 to run when a delete user is done..

They are installed in order.. A, B then C...

When A is installed the original hook is installed, When B is installed it includes the class from A and adds to it to perform its duties, And then finally C is installed and includes the class from B which already includes the class from A. This new class is the one that gets used to delete users...

The added bonus here is when we run the new Delete user function from The class C hook, it automatically deletes the users from A and B since they are included...

I am brewing up a concept to make this work but I am sure you get the gist of the power this allows.

Rodney

Quote:
I'm missing logic here. Class C extends a hook, it does not trigger an event. The event is triggered when scipt executions hits the hook point. Then hook point will run the abstract class which was extended by Class C, B and A.

Do you know iCms hooking system (preload)?

I am still getting up to speed here so I guess I should be considered a newbie.

I am about 2 and 1/2 books from feeling real comfortable about how this stuff all works but guess maybe I am jumping the gun a little bit.

Learning the ins and out of OOP with PHP now then off to frameworks, patterns etc last to be followed up by security before I start diving into more specific XOOPS stuff. Guess maybe I should sit back and watch more before I "jump" right in.

My intention with this was to show how you could have 3 different modules have their own versions of a similar "hook" incorporated into one hook. That hook could then be called by the system when needed as triggered by one of the three modules or by something else altogether unrelated and the methods defined in each module would each be run by being included in the main hook. Was assuming some things based on what I have learned so far and guessing on the things I have yet to learn based on what I have seen so far. Hoping that someone more experienced would see the logic and have the details worked out by the time I am up to speed and not only writing my own modules but helping convert some of the old modules.

May have been an expert in making computers talk to laboratory equipment in line based Basic and C but this PHP stuff is a lot more complicated and a lot more facets to it then I originally realized. Thank god for Amazon and $5 used books... ;)


Rodney