Details

• Notices are loaded by admin_notices action
• Operations may occur before hook that could display status messages

Implementation (Options)

1. Pass message to admin instance
• Parent object of View
• Need to define parent when creating view
• $view->set_parent($this)
• 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
2. 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
3. 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
• Not as possible in 1
• + No issues with undefined method names in Admin object
• Undefined filter hook fails elegantly