This still needs to be done and we need to decide on what the default should be.naderman wrote: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.
[RFC|Merged] General Hook Architecture of phpBB3.1
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
Nope as nobody replied, I'll do this if there are no objections?Oleg wrote:Was this done? If not I'm inclined to agree to add core_ for template events.Unknown Bliss wrote:We have a core. prefix for php ledges but not for template ledges. I propose we have a core_ prefix for template ledges.
Thoughts?
Formerly known as Unknown Bliss
No unsolicited PMs please except for quotes.psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
Some reference links:
Formerly known as Unknown Bliss
No unsolicited PMs please except for quotes.psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
Events dispatcher has been merged
To do:
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
- Resource Locator - Needs Merge Style Components
- Template Locator and Path Finder - Unknown
- Merge style components - Needs reviewing
Formerly known as Unknown Bliss
No unsolicited PMs please except for quotes.psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
- nickvergessen
- Former Team Member
- Posts: 733
- Joined: Sun Oct 07, 2007 11:54 am
- Location: Stuttgart, Germany
- Contact:
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
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:
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
Member of the Development-Team — No Support via PM
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
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.
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.
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
I agree with Joas, it is the best way to describe their location and normally their purpose.
Formerly known as Unknown Bliss
No unsolicited PMs please except for quotes.psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
+1 to Nils.
Also the rules suggested above look unnecessarily overcomplicated.
Also the rules suggested above look unnecessarily overcomplicated.
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
How is prefixing with core. followed by filename/classname/function overcomplicated?rxu wrote:+1 to Nils.
Also the rules suggested above look unnecessarily overcomplicated.
Formerly known as Unknown Bliss
No unsolicited PMs please except for quotes.psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
- imkingdavid
- Registered User
- Posts: 1050
- Joined: Thu Jul 30, 2009 12:06 pm
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
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.rxu wrote:+1 to Nils.