Anonymous | Login | Signup for a new account | 2024-05-02 20:45 CDT |
Main | My View | View Issues | Change Log | Roadmap | Docs | Wiki | Repositories |
Dependency Graph | [ View Issue ] [ Relation Graph ] [ Horizontal ] | |||
|
||||
|
Viewing Issue Simple Details | |||||
ID | Category | Type | Reproducibility | Date Submitted | Last Update |
0001224 | [In-Portal CMS] Email Templates | refactoring | always | 2012-03-14 12:06 | 2012-07-25 05:30 |
Reporter | alex | View Status | public | ||
Assigned To | alex | ||||
Priority | normal | Resolution | fixed | ||
Status | closed | ||||
Summary | 0001224: Email event usage refactoring | ||||
Description |
Currently e-mail event sending process (internally) doesn't represent real world model, which makes it hard to improve this code with new features. I'm proposing to: 1. create kEmail class with following public methods: - findEvent($name, $type) - setParams($params) - send() 2. make $this->sender refer to kEmailSendingHelper class instance for easy access across all methods 3. move existing code from EmailEventsEventHandler into new kEmail class 4. replace OnEmailEvent event sending with new kEmail class usage At the end interface of kApplication::EmailEventUser and kApplication::EmailEventAdmin will be almost the same (will return true/false instead of kEvent object), so no need to change code to make it working again. Usually nobody relies on e-mail sent fact in their code anyway. |
||||
Additional Information |
Main | My View | View Issues | Change Log | Roadmap | Docs | Wiki | Repositories |
Web Development by Intechnic In-Portal Open Source CMS |