Bug 113 - [Chameleon] Error reporting on Widget Minimum Attribute Requirements
: [Chameleon] Error reporting on Widget Minimum Attribute Requirements
Status: NEW
: Chameleon
Widget
: 1.99
: PC Windows 2000
: P2 enhancement
: FUTURE
Assigned To:
:
:
:
:
:
  Show dependency treegraph
 
Reported: 2003-11-13 11:58 by
Modified: 2004-08-10 20:03 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2003-11-13 11:58:36
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.
------- Comment #1 From 2003-11-13 13:14:47 -------
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.
------- Comment #2 From 2003-11-13 13:59:50 -------
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...

 
------- Comment #3 From 2003-11-13 14:00:27 -------
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' -->
------- Comment #4 From 2003-11-13 14:45:44 -------
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.
------- Comment #5 From 2004-04-06 13:12:49 -------
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.
------- Comment #6 From 2004-04-08 08:39:03 -------
updated version to 1.99
------- Comment #7 From 2004-07-07 17:27:11 -------
Changed target to 2.1.
------- Comment #8 From 2004-08-10 16:03:48 -------
Changed Target Milestone to FUTURE. (Enhancements may be moved from this target 
to specific "versioned" targets after product design review cycles.)
------- Comment #9 From 2004-08-10 20:03:40 -------
Changed severity to enhancement.