Consider event hooks in all HTML-generating code which allows a plugin to provide a CSS class name that is relevant to specific requirements. This is "context-sensitive CSS".
In each i_generate_html.php file, there is a call to a new function for my_css($f_bug_id). That function pre-loads a $t_css array with all of the default CSS classes used in the page. It then calls a new event to offer plugins a chance to replace class names. Then, rather than using the hard-coded class names, it uses whatever is defined in $t_css.
As an example, in bug_view_inc.php, right after this line:
Code: Select all
$t_css = bug_view_css($f_bug_id);
Code: Select all
function bug_view_css($t_bug_id) {
# pre-load default CSS classes for all fields displayed on the page
$t_css = array(
'bug-id' => 'bug-id',
'bug-date-submitted' => 'bug-date-submitted',
'bug-reporter' => 'bug-reporter',
'bug-priority' => 'bug-priority',
'bug-due-date' => 'bug-due-date',
'bug-due-date overdue' => 'bug-due-date overdue',
...
);
return event_signal( 'EVENT_CSS_ISSUE', array( $t_bug_id , $t_css ) );
# That invokes one or more plugins to read the issue for the provided ID, and then
# determine non-default CSS classes to display specific fields.
}
Code: Select all
if( $t_bug->category_id == 50 ){ $t_css['bug-priority'] = 'bug-priority priority-urgent'; };
Code: Select all
echo '<td class="<?php echo $t_css['bug-priority'] ?>">', $t_priority, '</td>';
Code: Select all
bug-priority priority-urgent { color='red'; }
I think this will add a small amount of overhead to processing. Someone might suggest that the elements replace the entire class="foo" text rather than just the class name - for example, reference specific elements by page and ID rather than one class for all similar elements on a page. That could be a flaw in this plan, evident in any page that displays multiple bugs. I can look at that.
Please provide thoughts on this event/plugin proposal.