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

1: ::xowiki::Form constraint parameter always false regardless of passed value

Posted by Richard Hamilton on 02/22/13 12:21 AM

Perhaps this is a stupid mistake on my part, but I've wasted at least 4 hours trying to work out why my ckeditorv4 code is not working as expected, and I've traced it to this problem which also seems to happens with the existing ckeditor integration.

When I put this in the form constraints:

{test01:optional,richtext,width=60%,label=Test01,inplace=true,editor=ckeditor}

....and put a util_user_message at the top of the ckeditor render_input method, I get the value 'false' displayed for the inplace property (which is its default value that is hardcoded in the richtext::ckeditor parameter declaration in form-field-procs.tcl). If I set the default to true, then true is displayed by util_user_message, and again I cannot over-ride to false in the form constraints.

I am completely at a loss. Why is that? Why does it ignore the parameter value?

I have tried server re-starts, re-loading files. Absolutely confounded, and self-harming with frustration!! :-|

As a second question, I have tried adding an additional property, as an experiment, in the property declarations for richtext::ckeditor in form-field-procs.tcl. I can set {mytestproperty=false} and use util_user_message to display this value without a problem, but I am not permitted to set the value for it in ::xowiki::Form constraints like this:

{test01:optional,richtext,width=60%,label=Test01,mytestproperty=true,editor=ckeditor}

...becuase it throws the following error:

Error in field Form Constraints: From field 'test01' (class ::xowiki::formfield::richtext) has unknown attribute 'rhtestproperty'

Clearly the form validation is set somewhere else? How should this be achieved?

2: Re: ::xowik::Form constraint parameter always false regardless of passed value (response to 1)

Posted by Gustaf Neumann on 02/22/13 09:41 AM

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

3: Re: ::xowik::Form constraint parameter always false regardless of passed value (response to 2)

Posted by Richard Hamilton on 02/22/13 11:17 AM

..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.

4: Re: ::xowik::Form constraint parameter always false regardless of passed value (response to 3)

Posted by Gustaf Neumann on 02/22/13 04:29 PM

i have added a paragraph in this direction to the xowiki introduction.

5: Re: ::xowiki::Form constraint parameter always false regardless of passed value (response to 4)

Posted by Richard Hamilton on 02/22/13 05:02 PM

I've just read it, and it is a very clear and helpful addition.