Changed target to 1.99 RC 1.

currently only mandatory attributes are validated to exist.  All other
attributes are assumed to be either correct or not there.  Adding validation of
all attributes would cause considerable overhead in php processing (I'm guessing
it would add 5% on a moderate sized template).  I'm not really keen to add this
new feature, but will defer if someone has a good argument for why it is needed.

Comment #2 makes a lot of sense to me.  Suggestion:  maybe we could have a tool
for Chameleon application developpers to validate their application on demand.

there is a parameter in chameleon.xml to enable/disable template validation.  It
is on by default but it is recommended to turn it off in a production
environment to provide best possible speed.  I wonder if anyone ever does? 
Anyway, this would satisfy my concerns I guess.

This is a good idea.  This is my setting:

        <param-name>validate_template</param-name>
        <param-value>true</param-value>

But I guess it doesn't validate all possible attributes.  Doen'st it?

right now it only validates the ones it finds, it doesn't validate the
extraneous ones.  The modification would be to test all attributes and if an
attribute isn't in the list, generate an error message.  Now that I have thought
about it more, I think that this can be introduced with very little impact.  I
had originally thought this would be a much more expensive thing to do, but I
think it is an important validation tool for application developers.

implemented in cvs.  I was going to make widgets invalid if they didn't have all
valid attributes, but I discovered that most of the samples have invalid
attributes in most of the widgets, so I left this out for now.  The next stage
of this bug is to fix all the templates in the sample application so that no
verification errors occur.  Then we can enable invalidating widgets with invalid
attributes for the final release.

Does someone want to volunteer to go through all the templates with this and fix
the problems encountered?  Also note that any attributes that are valid for the
widget but are not properly declared will also show up, which should help out
verifying for documentaton purposes.

does this mean that when we release beta 3 that most sample applications will be
invalid?

If yes, than we have two options:
1) roll back this modification for beta 3
2) rush through and fix these applications?

I will volunteer to do this, but I would of course prefer no to be rushed :) I
could have these apps validated by friday of next week (if not rushed) or by
this monday if rushed.

I am now convinced this is a pretty essential change and I want it included as
early as possible to get people used to it.  I'm getting low on Beta 3 issues to
deal with (finally ;)) so I'm going to give this a first pass today and try to
clean it up as best as possible.  I'll leave the task of validating my work to
Chris when the next beta 3 is released.

should the target be still 1.99 RC1 just incase there are future issues and/or
modifications?

If you need help paul with validating apps let me know which onces you want me
to do.

Changed target to 1.99 Beta 3.

All templates validated and fixed (there were a number of changes).  Also, I
found and fixed a serious problem in the LegendTemplate widget (it would
probably have screwed up the doc generator ... was there a bug on that? perhaps
bug 722?  In any case, the widget was not registering attributes for Button and
Popup and now it is :)

Also modified the Button.php code to include LABEL which was used but not
registered.

Also modified error reporting to include the whole widget tag in the message
since it was difficult to find the offending tag if mulitple widgets of the same
type existed.

Marking as fixed in cvs, pending validation.  I'm happy with the state of this
for beta3 so I'm targetting RC1 for validation.