[RFC|Merged] General Hook Architecture of phpBB3.1

[Oleg]

It would be great if we can resolve extensions at compile time and at runtime based on maybe a define in config.php. Projects like debian, run multiple boards with a single code base, they rely on the template cache being usable by all boards. If extensions are compiled into templates, this will no longer be the case. However compiling them in might be faster. So having them resolved at compile time would be the default, but a define would allow moving all extension related calculations to runtime.

This still needs to be done and we need to decide on what the default should be.

[MichaelC]

We have a core. prefix for php ledges but not for template ledges. I propose we have a core_ prefix for template ledges.

Thoughts?

Was this done? If not I'm inclined to agree to add core_ for template events.

Nope as nobody replied, I'll do this if there are no objections?

[MichaelC]

Some reference links:

• Old hooks system & events to allow overruling of functions
• IRC Log for the above
• Template locator and finder combination so we can use template inheritance

[MichaelC]

Events dispatcher has been merged

To do:

• Add composer to build script
• Template Inheritance
• ACP Template hooks
• Have at least 30 php events, 30 template events and 20 ACP template events
• A new tracker component for events

Requires:

• Resource Locator - Needs Merge Style Components
• Template Locator and Path Finder - Unknown
• Merge style components - Needs reviewing

[nickvergessen]

Pulling this up again.

Oleg and I had some discussion about the naming of the events.

We use core. as a prefix so far. I would also add the following rules:

• If an event is in a root-file it should be prefixed with the file name, e.g.:
  Event to change the page title in index.php: core.index_page_title
  
  
• If an event is in a class it should be prefixed with the class name, e.g.:
  Event to modify data in acp_forum.php: core.acp_forum_modify_data
  
  
• If an event is in a function it should be prefixed with the function name, e.g.:
  Event when changing the username with function user_update_name(): core.user_update_name_after

[naderman]

I am entirely against using filenames, class names or function names in the event names.

Events are independent of the exact location they are currently implemented. One of the big advantages of events is that they can keep working when we decide to rename or move functions, classes or files. They even continue to work when we use them in a different place providing the same context.

So instead we should come up with consistent naming that does not directly relate to where they are placed, but clearly describes their purpose.

The only exception I can see is with some very commonly used phpBB function names, but that should be the only exception.

[MichaelC]

I agree with Joas, it is the best way to describe their location and normally their purpose.

[rxu]

+1 to Nils.
Also the rules suggested above look unnecessarily overcomplicated.

[MichaelC]

+1 to Nils.
Also the rules suggested above look unnecessarily overcomplicated.

How is prefixing with core. followed by filename/classname/function overcomplicated?

[imkingdavid]

+1 to Nils.

Basically, once an event is named, it should not have its name changed, as that would destroy backward compatibility. If we are naming based on file/function/class and that specific code gets moved, we either have a misnamed event, or we have to rename it.