Hook system

[Tomasz Czauderna]

I declare to working with some extra futures.

And i  will plan started in short time.

But i look Yet on froxlor. Maybe better start to make something based on hook system this will be better for many reasons 

• Easiest implementation
• Faster development
• Plug-in system
• All existest futures make be ported to this system

Benefits smallest files and core will be separated not every time all will be parsed if not enabled.

All sorce should be more readable

 

We can do something based on open source or make something simple to realise this element

 

What's Your's opinion about this

[d00p]

We have had this idea before...basically, just putt something like "Hook::callHook('name')" at any position you want to implement a hook. then have a static Hook-class that searches (defined) paths for files providing the hook-function 'name' and run it. 

[eis_os]

Hello

 

Maybe still useful for someone:

-edit-

(Don't use it in current form, only as source for ideas)

-/edit-

https://github.com/eis-os/Froxlor/tree/plugin-system

• Hook System
• Plugin System
• Install / Update System for Plugins (easier to track changes)
• Settings Wrapper

 

Events are globally defined in /lib/classes/event/class.FroxlorEventConstants.php  (only some are defined yet)

FroxlerEvent is the static class as glue between Froxlor and Froxlor Plugins.

 

A plugin extends /lib/classes/plugins/abstract.FroxlorPlugin.php, 

internally it does automatically setup the necessary event functions, load language files and so on...

[d00p]

Latest commit bc336c6 on 13 Jun 2015....

 

and why advertise your fork if you could for example contribute things like that as pull-request?

[eis_os]

Sorry, you get this wrong, this could be a start for a "proper" patch. Nothing that should be used out of the box in it's current form as the events currently leak to much of the "internal" State of Froxlor. (Specially the Cron Task IDs).

[d00p]

aha...

[pquerner]

Think of the Magento Shop Event System. In some classes you'll find the Event Dispatcher, which dispatches a current event (say "customer_logged_in" (example, may not exist)) and with it, it'll ship the current context with it. (probably the class itself $this). 

The event dispatcher iterates through configurated plugins/modules/extensions (whatever name you want to use) and executes their logic.

 

Pros

- multiple extensions can use the hook/xclass/event

- ...

 

Cons

- first come, first serve. Second in line will get already altered data. (Magento will allow you to specify dependencies in your modules configuration so you may be loaded before/after module XY)

- ...

[eis_os]

Well you can use FroxlorEvent::fire('CustomEvent', $eventdata);
If one module depends on the other, they could theoretical use events (and if something is missing it simple won't get an answer).

I made a pull request for the current changes (rebased and updated to last release):  https://github.com/Froxlor/Froxlor/pull/344

Do I think it's the right way? Depends. From the technical standpoint plugins can run on their own quite nicely.
when they need to interact with code in Froxlor there are lot technical problems with the current codebase.

I use the plugin system to create nssextrausers and autoconfiguration of thunderbird clients (adds a alias line to apache config), so nothing big yet.

For testing purpose I wrote a plug-in to manage additional let's encrypt certs database entries, to see if the code works for UI tasks.
Froxlor leaks to much state in global variables, the UI plugin code code currently gets tunnelled via admin_plugin.php and there are still to much hardcode dependencies, like for doing a redirect.