Proposal for Context-Sensitive CSS Plugin
Posted: 23 May 2019, 15:59
In response to a challenge to customize the display of a specific field in the bug view, I was thinking about a more global solution. This is significant because it's a proposal to change the way most fields in the environment are displayed.
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:
That new function looks like this:
A site-specific plugin might have this line:
Now later in bug_view_inc we would see this :
The result is that the CSS for every field in the bug view can be customized on a per-bug basis, per project, per user, or for any other criteria. The developer would need to provide CSS overrides for anything referenced in their plugin. In the above example:
This concept can be extended to many pages in Mantis. The above function bug_view_css is specific to bug_view_inc.php, but over time, other modules that generate HTML can get their own foo_css function, and developers will just need to handle the event in this plugin.
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.
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.