You need to log in before you can comment on or make changes to this bug.
Error reporting on Widget Minimum Attribute Requirements This is another comment on how to help the user understand what widget attributes are missing/needed for their widget definition </CWC2>. If a widget attributes is required to make this widget work and are not found in the widget definition, than an error message should be displayed. NOT the "red <CWC2/> text of death". I realize that this may be difficult to manage for each widget, but it is my hope that this information will be documented in the *.xml help files. Where each widget will have the information for the minimum attributes requirements. Which then could be extracted and verified during testing mode of building a CWC2 template.
Widget attributes are supposed to be automatically checked when Chameleon loads widgets. Each widget indicates which attributes are optional and which are mandatory. If a mandatory attribute is missing, then you will get the "red tag of death" in your template, but you will also get an error in the error manager. If you have included an error widget in your template, you would see a message saying that the attribute was missing (and it would tell you which attribute it was). This may not the best way of handling things for a number of reasons, and this is one of them. But I am not sure what the correct approach would be. I am open to suggestions on this.
I guess the problem lies in the fact that during single template testing the errorreporter widget should be present. The other comment how to you debug the errorreporter widget ;) One thought could be instead of duplicating what is produced in the errorreporter. What about highlighting certain aspects of the "red tag of death" (R-Tod) different colors. eg. light blue-> correct attribute for widget red -> incorrect attribute specification. bold red -> missing required tag. This of course would mean you would edit and brake up the CWC2 string being displayed. But could be very powerful in showing errors. This color-coding behavior could be also applied to what parameter group the cwc2 attribute is from eg. BASE ATTRIBUTES, LABLE ATTRIBUTE...
How about including HTML comments describing the error in the source at the location of the widget at the same time as you insert the red tag stuff in the template (similar to what we do with the warnings in MapServer GetCapabilities). e.g. If the tag is red'ified because the widget doesn't exist then you would get: <!-- CWC ERROR: Unable to widget of type 'bogus'. Please verify the the 'type' attribute of the CWC tag refers to a valid widget type. --> If it's a missing atribute then you would include something like: <!-- CWC ERROR: Mandatory attribute 'blah' missing for widget of type 'whatever' -->
Maybe it have nothing to do with this bug, but I already outputing some info as html comment in chameleon when an error occure. For instance, if a ParseURL failed, then we have the exact Widget thayt failed as HTML comment. Also if we get in some infinit loop when using template redirection, again, an HTML comment is outputed to help me to understand what happened.
There is a problem with outputing the ParseURL comments, they are output immediately when they are found, which is before the template is output, so the resulting HTML returned to the browser is screwy ... i.e. you have valid HTML before the <html> tag coming from the template. This also breaks any attempt to use the output buffer compression with ob_start (this is not the only thing that breaks it though) Not sure what a better way of handling it would be though (ParseURL failures). I also agree with Daniel's comment that widget errors could be output as HTML comments, that would make some types of debugging much simpler and would help in the case of the single widget test template because errors would then be displayed (or could be). I think this is a post 1.99 issue though.
updated version to 1.99
Changed target to 2.1.
Changed Target Milestone to FUTURE. (Enhancements may be moved from this target to specific "versioned" targets after product design review cycles.)
Changed severity to enhancement.