https://bugzilla.wikimedia.org/show_bug.cgi?id=31911
--- Comment #3 from Van de Bugger <[email protected]> 2011-10-24 19:52:06 UTC --- `#iferror' is a part of widely used ParserFunctions. Attachment is just a proposed patch, I am not insist on any particular implementation. My concerns is that (1) error and warnings are not distinguishable from normal text, so some kind of <span> is required for formatting purposes, for handling with JQuery scripts, etc; (2) well-known and widely used ParserFunctions' `#iferror' does not recognize errors. Introducing a new function is ok if it will be called "behind the scene". I mean, usual, currently working code: class MyExtension extends ParserHook { function getName() { return 'MyExtension'; } function getParameterInfo( $type ) { $params = array(); $params[ 'param1' ] = new Parameter( … ); … return $params; } function render( ) { return 'result'; }; } should return error message properly formatted (with <span class="error">/</span>) with no changes. > My concern with this patch is that this pretty much forces extensions to get the errors in a span with class error. To me this is right behaviour bcause: 1. Span of class `error' will be properly formatted, because it is present in `skins/common/shared.css': .error { color: red; font-size: larger; } 2. `span' is safest HTML element, suitable to appear inside any other elements, either inline or block. About warnings: Many different message levels (fatal error, errors, warnings; btw, syslog supports 8 levels) would be nice, but… To me it is not a high priority task. I would like to have better reporting first. For example, I want an error message includes error location: source page name, line and position number. I want it includes "stack unwinding" info, so I can easily track the error. For example, now I see an error message (wording is not exact): syntax error: escape is not a valid parameter. But where is the error? What function/template generated it? From which template is is called? Each time I have to guess, to look trough my templates searching the exact location of the problem. Ok, get back to the stream. I think Validator can support multiple message levels, warning/errors/fatal errors, etc. However, by default all the level should be splitted into 2 groups: (1) fatal errors and (2) non-fatal errors. 1. Fatal errors are returned instead of normal result, and surrounded with <span class="error">/</span>. 2. Non-fatal errors are discarded, normal result is returned. If FirePHP is installed, it is used for reporting: if ( isset( $wgFirePHP ) ) { $wgFirePHP->log( ... ); # or $wgFirePHP->info( ... ); # or $wgFirePHP->warn( ... ); # or $wgFirePHP->error( ... ); # depending on message level } -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
