SLB: Notes – Admin: Views: Displaying Notices
By Sol in Lab
Details
- Notices are loaded by
admin_notices
action
- Operations may occur before hook that could display status messages
Implementation (Options)
- Pass message to admin instance
- Parent object of View
- Need to define parent when creating view
- Send messages to parent as needed
$this->parent->set_message($msg)
+
All messages are aggregated in single object — no need to iterate through Views
-
Must track/save additional object (parent) — more complicated to use
+
Parent/child connection can also be used elsewhere
- Global options, labels, etc.
-
Dependency: Methods in parent could change
- Making calls to parent from child cause errors
- Set hook on View
- Example:
add_action('admin_notices', 'show_messages')
+
Views display their own messages independently
?
Requirements (properties)?
- Save message to View
- Flag that filter has already been set (so hook not added multiple times)
+
Simple implementation
-
Decentralized control — may be harder to make changes in the future
- Send messages to admin object via hook (filter)
- When message needs to be set in View:
add_filter('slb_admin_notice', 'get_notices')
- Must set flag in View to limit hooks set to single call (
notice_set
)
- When main object needs messages:
apply_filters('slb_admin_notices', array())
View->get_notices()
adds notices to array
+
Messages managed independently by each View
+
Admin object does not need to handle messages until they are required
-
Must run through filter process to determine if any views have messages
+
Should be fast if no hooks have been set by Views
- Though not as fast as checking property on Admin object in 1
+
Possible to add/remove notices set by View until they are fetched
+
No issues with undefined method names in Admin object
- Undefined filter hook fails elegantly