Forum OpenACS Development: Re: ::xowik::Form constraint parameter always false regardless of passed value

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

..and with a single golden grain of fairy dust, as if by magic, the problem goes away, the blood pressure drops, calm returns! :-) Thank you - very much.

This one little golden nugget of information explains the previously confusing fact that I had previously successfully defined and used a 'callbackobject' property without seeing a problem. How? Two reasons:

1) the name was not overloaded in superior classes
2) I had not made a stupid mistake with the name. I checked, and you were absolutely correct, the error did say 'mytestproperty' because this is what I had typed into the form constraints despite putting 'rhtestproperty' into the form-field code. So I typed in the wrong thing, and then couldn't see it no matter how many times I looked at it. I think this is known as 'missing the gorilla'! (Incidentally, I was able to see this after you message because when trying again I made the same typing error again!) Oh the fallability. :-|

Now that the parameters are in the correct order, the value of inplace is correctly passed through.

Oh...thank you.

R.

i have added a paragraph in this direction to the xowiki introduction.
I've just read it, and it is a very clear and helpful addition.