tags:

views:

165

answers:

4

I'm learning xForms, but apparently not well enough because I can't figure out why this code doesn't work.

It parses in FF2 w/ the xForms extension but does not render the form controls. IE7 and X-Smiles give me different problems, but I'm not sure if those problems are becaause of my xForms or because of something else- until I get it working in FF2 I can't really tell.

A: 

You shouldn't place your models in the body section. Instead all model definitions should be in the head section. As it is now, your code isn't standard compliant and is very difficult to understand.

Xforms Wiki book is a good resource for learning XForms.

kgiannakakis
Actually, your point about not putting model into the body is not true. The XForms spec is intentionally agnostic about details of the host language and doesn't mandate anything about the location of model at all. Indeed, one major implementation of the spec, Ubiquity XForms, actually requires that model elements be present in the document body due to browser limitations.
Phil Booth
A: 

I'll add that xf:repeat, xf:group, xf:input,... can't be children of xf:model

A: 

A good place to start could be an XForms validator. Afterwards, I'd recommend starting from a working example and adding your code gradually, to observe which part is failing.

l0b0
+2  A: 

This document contains a ton of problems unfortunately, I'll go through each of them in turn.

1) The biggest problem occurs a few times and seems to stem from some confusion between the model and the UI. The two are entirely separate beasts in XForms, which adheres to the model-view-controller design pattern. So you need to remember that everything in the model is entirely separate from everything in the UI. The relationship between the two is simply that UI controls may bind to instance data nodes in your models. Practically, in terms of your document, this means that your select1 and repeat elements should not be children of model elements. Only instance, bind and the action elements may be children of model.

2) You are using multiple model elements, which is unnecessary in such a simple form (because each model may contain many instances and binds). The reason I flag this is up is because you introduce a couple of potential pitfalls by using multiple models, which are best avoided by sticking to one model where possible. For example, the instance XPath function will not work across models, so you have to be very careful about data dependencies between them. Also, a UI control is refreshed according to which model it is bound to, which has often caused me problems in the past when controls are apparently not refreshing sanely.

3) You've tried to use a repeat element to apply a child bind to many nodes. This is wrong because repeat is a UI element, not a model element. However, since bind takes a nodeset attribute instead of a ref attribute, you don't actually need a repeat at all. Instead, you can just do this:

<xf:bind nodeset="//want" readonly="true()" />

4) On many of your UI controls, you are specifying both a bind attribute and a ref attribute. These attributes are mutually exclusive, since they represent different ways to achieve the same thing. The ref attribute should contain XPath that identifies an instance data node that you want to bind the UI control to. The bind attribute should contain the id of a bind element that has been defined elsewhere (the bind element itself will identify the node that the control binds to in this case, via its nodeset attribute). So by using both attributes on the same UI control, you are contradicting yourself.

5) In some places, you've attempted to use a ref attribute to bind a control to another element in the UI. Controls may only be bound to instance data.

6) You have a setvalue inside a repeat, which you are attempting to invoke on the xforms-value-changed event. This event is not dispatched to the repeat element, so your setvalue will never be invoked. The xforms-value-changed event is only dispatched to the core form controls, which are defined in the XForms spec as:

input|secret|textarea|output|upload|range|trigger|submit|select|select1

7) Another answer to this question mentions that you are wrong to put your model elements in the document body. Unfortunately I don't have enough reputation to comment there, but I just wanted to point out that answer is actually wrong. Although it has become conventional to put the model elements in the document head, nothing in the XForms spec mandates this. In fact, one major XForms processor, Ubiquity XForms, actually requires models to be in the document body, because of browser limitations.

Phil Booth