In XForms Controls form:

• click the button → the menu shows but disappears right away

In Controls form:

• the first time only the menu shows and you can select a value
• clear the field
• subsequent times the menu shows but selection doesn't have an effect

For example, the following page produces 70 errors:

http://validator.w3.org/check?uri=http%3A%2F%2Fdemo.orbeon.com%2Forbeon%2Ffr%2Forbeon%2Fdmv-14%2Fedit%2F6b01fa4cd1605b8f736fac09be6cf9b2&charset=%28detect+automatically%29&doctype=Inline&group=0

We send the HTML 5 DTD by default. See #306.

Currently, inserting/modifying controls will attempt to modify the XML data model. This must not happen when a custom XML data model is in place.

Requirements:

• form data must at least support owner/author/visibility metadata
• all accesses must be controlled based on those criteria
• summary page must be able to filter search based on those criteria

A simple Unix-like authentication scheme like that of eXist might be desirable.

This is happening as the JavaScript hasn't been loaded in the page when it was first served to the browser. It looks like we either need:

1. To include the JavaScript/CSS for all the possible XBL components in the page when it is first sent to the browser.
   1. When creating a new form, we only know the list of components after users enter the app/form names. So we would need to go through all the oxf.fb.toolbox.group.*.*.*.* properties, collect all the distinct XBL files.
   2. Go through each XBL file to collect the distinct XBL components.
   3. Include a non-relevant instance of each XBL component, so the XForms engine includes the appropriate JavaScript/CSS in the page.
2. To implement a mechanism for the server to send new JavaScript/CSS to the client.
   1. The server needs to know if a given piece of JavaScript/CSS has been sent already, so not to send it again if this isn't needed.
   2. The Ajax response needs be able to contain either inline JavaScript (e.g. for the JavaScript included in the page for <xxforms:script>) and links to JavaScript files. Ditto for CSS.
   3. The client-side code needs to be able to load JavaScript and CSS, both inline and by URL. We already have code doing something similar in DeferredPortletLoader.coffee.
   4. The client-side code might need to initialize the code being loaded, depending on whether listeners to YUI's onDOMReady and jQuery's ready() are called right away when the JavaScript is loaded.

Repro:

• insert new repeat
• notice dark bottom of grid is missing

Right now, xxbl:global scopes everything in the top-level scope. This is problematic:

• it breaks encapsulation (global elements are just copied to the top-level)
• it can lead to id conflicts
• accessing the top-level scope is not always possible

The idea is to scope globals in a new scope per XBL binding id (not per concrete binding as the scope is shared amongst concrete bindings).

1. Create a form in Form Builder
2. Add a static image field, attach an image
3. Save and publish the form
4. Open the new page => the image shows fine
5. Hit save => image shows "broken"

Steps:

• http://localhost:8080/orbeon/fr/orbeon/newbuilder/new
• insert Date Time control
• click on date field
• notice control is cropped

"The regular expression in replace() must not be one that matches a zero-length string"

With FB create a form with Number control and observe error when testing the form.

Make sure to run in dev mode.

The resource aggregator has limitations:

1. you can't add your own resources to the baseline
2. you can't add tree/menu/etc. to the baseline

Point 1 could be improved by adding a configuration property to not only specify components part of the baseline, but also resources by path.

Point 2 can be improved by XBL-izing those components.

See reproducible example:

https://gist.github.com/2003842

And thread in ops-users:

http://orbeon-forms-ops-users.24843.n4.nabble.com/Initial-selection-in-select1-appearance-compact-doesn-t-work-in-Firefox-td4431190.html

In the new builder, mousing out of the grid at the top hides the icons, so you can't insert or delete columns anymore.

So far, the server doesn't handle focus besides:

• changing repeat iterations when events occur on controls within repeat iterations
• propagating DOMFocusIn/Out sent by the client
• telling the client to focus when xf:setfocus is called

In addition, focus events are broken in XBL, in the sense that they are incorrectly retargeted outside the the shadow trees.

What we need:

• server to fully track focus
• dispatch focus in/out events not only to focusable leaf controls but also to container controls
• in particular, dispatch focus in/out events to XBL controls when needed
• update focus when focused control becomes non-relevant, readonly or non-visible (case, dialog)
• update focus when iterations disappear
• update focus upon repeat iterations changes including via setfocus, insert/delete

Steps with form provided by customer:

https://orbeon.basecamphq.com/C159073265

This was suggested by a customer. Say you import or embed a schema. That schema might contain:

• enumerated values
• annotations

Currently, if you need such information, you must also include the schema into an instance. The idea of this RFE is to provide easier / more efficient access to this via XForms. Ideas include:

• providing access to the schema as a document (then using e.g. a custom function to extract information from it)
• an extension function such as xxf:schema-annotation($instance-element, $lang?)

Repro: go to a form, navigate forward then back, notice error:

java.lang.AssertionError
at org.orbeon.oxf.xforms.control.controls.XFormsOutputControl.evaluateExternalValue(XFormsOutputControl.java:123)
at org.orbeon.oxf.xforms.control.XFormsValueControl.getExternalValue(XFormsValueControl.java:197)
at org.orbeon.oxf.xforms.control.XFormsValueControl.getBackCopy(XFormsValueControl.java:232)

This is good for testing, but makes controls no longer accessible. Find a solution.

With Chrome:

• http://localhost:8080/orbeon/fr/orbeon/newbuilder/new
• insert Date field
• click on date -> picker shows
• insert row in grid
• insert Date field in second row
• click -on date -> picker doesn't show

Evaluating the ref of a setvalue with if="false()" but not if there is an enclosing action with a if="false()" is inconsistent. (One could argue that it is always analyzed and leads to an error if an undeclared variable is used, but this isn't what is happening.)

Test case

For consistency with what happens for regular sections, having the elements for non-relevant section templates present in the instance is desirable. On way to deal with this would be to have, as part of the Form Builder meta-data for XBL components, a template for the XML to add inside the element in the instance. With this:

• When creating the XBL component from the library form, we should populate that XML template.
• Form Builder, when adding the component, should add the elements in the template inside the element from the instance bound to the control.

Also see Why are the elements for a non-relevant section template missing?

Repro: simply try the Contact form in noscript mode. Screenshot:

http://twitpic.com/8r5r8g/full

Was added on the parent of the <span> element it should go on, because for booleans we don't have a <label>.

jQuery will allow us to write simpler client-side code, and in the short term to solve issue #46.

Steps with new builder:

• insert new repeat
• insert dollars and cents field
• enter a number in the field and tab out (this works)
• insert a new repeat row ("+")

Issue 1: Notice that the field in the first row is now empty.

Issue 2: Notice that the field in the first row doesn't work anymore. The field in the new row does work.

This is probably due to the fact that the JavaScript doesn't restore the first field.

Repro: select sizes in "Page size: | small | large | larger | 100%" selector. The size doesn't change anymore.

We need to use jQuery to register the change event listener when using jQuery Mobile.

1. Run https://gist.github.com/1791298 in the XForms sandbox.
2. In the Chrome console, run: $$('tr[class = " xforms-repeat-template"]') => it return the "faulty" repeat template with the space in front of the class name.

The "+" icon to add languages is missing.

Currently, if an iteration moves between the start and end of an upload, the value of the upload might be set into the incorrect iteration.

Think about how to track the iteration, maybe with by tracking the correct repeat iteration with start/cancel/end events.

See #31.

Implement a mechanism for the server to send new JavaScript/CSS to the client.

1. The server needs to know if a given piece of JavaScript/CSS has been sent already, so not to send it again if this isn't needed.
2. The Ajax response needs be able to contain either inline JavaScript (e.g. for the JavaScript included in the page for <xxforms:script>) and links to JavaScript files. Ditto for CSS.
3. The client-side code needs to be able to load JavaScript and CSS, both inline and by URL. We already have code doing something similar in DeferredPortletLoader.coffee.
4. The client-side code might need to initialize the code being loaded, depending on whether listeners to YUI's onDOMReady and jQuery's ready() are called right away when the JavaScript is loaded.

See:

http://orbeon-forms-ops-users.24843.n4.nabble.com/Issue-with-radio-button-and-internationlization-tc4331670.html

I reproduce this.

Say you switch between model1 and model2 in the view. You see the following variables:

• view variables up to switch to model2
• model2 variables (incorrect)
• view variables up to the top
• model1 variables (incorrect)

Repro:

• go to http://localhost:8080/orbeon/fr/orbeon/dmv-14/edit/6b01fa4cd1605b8f736fac09be6cf9b2
• remove vehicle
• add vehicle
• JS error

It seems that a delimiter is missing, but it's not clear why. Also, in the Ajax response, old-index has value 0. Is this expected? old-index is not used by client anyway, but is this a symptom of something else?

1. Add a Dollars and Cents control
2. Click on it and without moving the mouse type 42
3. Move the mouse outside of the cell

The value get "committed", as if the user had tabbed out of the field.

See the in-progress specification:

http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#The_switch_Element

Currently, this property doesn't work with the new grid editor.

Repro:

• insert new repeat
• insert control in cell
• hover over cell, notice no icons

Works with Chrome.

Repro:

• Contact form in noscript mode (http://localhost:8080/orbeon/fr/orbeon/contact/edit/fbbc3d94899ad5f132d65e059befda24?fr-noscript=true)
• enter accented character in field (e.g. "é")
• navigate to Review
• notice broken accented character in field

Also happens if you enter e.g. accented characters in fields. This used to work. Screenshot:

http://twitpic.com/8r5s37/full

Repro: in Controls form, remove and then attach a new, fairly large picture. It goes over the boundaries of the cell.

Screenshot:

http://twitpic.com/8r5xsu/full

The idea arose when thinking about more i18n mechanisms for the XForms engine / Form Runner.

Some thoughts:

• write a property: set-property('my.foobar', value) or set-property('xxforms:foobar', value)
• read a property: xxforms:property('my.foobar) or property('xxforms:foobar')
• a property set via this mechanism overrides Orbeon Forms and model properties
• the default values comes from Orbeon Forms and model properties
• values must be part of the dynamic state (and serialized when needed)

XForms 1.1 does not allow this. However we do, but when a value is entered by the user this error occurs. Should we make controls bound to complex content non-relevant? See example:

https://gist.github.com/1689903

The logic should be the same as the one implemented for the <xforms:textarea mediatype="text/html">.

Currently, controls within a non-visible dialog are still evaluated, which is not efficient.

NOTE: Probably that just the content of the xxf:dialog element should be non-relevant, and the xxf:dialog element itself should remain relevant, so that it can receive events, in particular.

See for instance what we do in the autocomplete.xbl. (A newer version of this code will listen on an event targeted at an enclosing group, and forward that event.) The XBL engine could always do this automatically for the component. The component could opt in for this to happen, but I can't think of cases where we wouldn't want this, other than maybe for backward compatibility, so we could have the focus handling always handled by the XBL engine by default.

With Chrome:

• insert one repeater -> bottom border appears ok
• insert 2nd repeter -> bottom border appears ok for 2nd one, but missing on 1st one