To answer the questions with confidence, i would have to look at the details (source).
Most likely, the error message in your posting does not say "unknown attribute 'rhtestproperty'", but "unknown attribute 'mytestproperty'". But this might be a hint about the missing piece in your picture: Note, that the form constraints are processed from left to right. In this process, the class of the form field (and defaults for its attributes) can change multiple times, and depending on the change, other attributes are applicable. Let us take the example from your last last line:
- "test01:optional" creates a generic form field (class "text"). As an instance of this class, it has the attributes of its inheritance tree assignable to it. The instance of this class gets the instance variable optional set to true.
- "richtext": reclass the form field to class richtext (full name ::xowiki::formfield::richtext). This adds the possibility to add all form field properties that a "richtext" offers. During reclassing, set some instance variables might be set to default values, depending on the definition of the class.
- "width=60%", "label=Test01": set these instance variables of the form field of class ::xowiki::formfield::richtext
- "mytestproperty=true": Since the class ::xowiki::formfield::richtext has no attribute with this name, the error message is thrown, and the processing stops here.
- "editor=ckeditor": the last part of the form constraints is here example interpreted due to the earlier error. Since you have most likely defined the "mytestproperty" on your modification of class ckeditor, this definition comes too late.
My recommendation is to reformulate the form constraints as
{test01:richtext,editor=ckeditor,width=60%,label=Test01,mytestproperty=true,optional}
The reason for the approach with reclassing is for composing form constraints from multiple sources with various weights. For example, with an xowiki workflow, the actual form constraints are composed from the form-constrains defined in a form, the form-constraints defined for a certain state and the form-constrains for the whole workflow. This allows e.g. the the same content might by seen from one user in role A as "text" and from a user in role B as "label", or not-modifiable, or it might be omitted, etc.
I would not be surprised, if the reordering helps for the first problem case as well. Hope this helps!
-gustaf neumann