Re: No value changed initialization and instance replacement fix (continued from telecon minutes)

All,

We have to separate questions here:

1. What to do during initialization.
2. What to do upon instance replacement.

1. What to do during initialization
-----------------------------------

 > We intentionally do not issue value *changed* and other events on UI
 > initialization.
 >
 > We don't do it when the UI is first created during model construct
 > done default processing, and we don't do it when new controls are
 > created in response to dynamic changes to the form, such as a repeat
 > generating an additional set of controls.
 >
 > In general, new UI controls are expected to be able to get their
 > values and MIP states directly from the XForms processor *without*
 > events being fired.
 >
 > Note that we especially point out in model-construct that no
 > xforms-refresh is issued on initialization, and that
 > model-construct-done *creates* the UI.  There is no refreshment
 > needed because it just got created!

I wrote initially: "Point taken regarding xforms-value-changed."

But in 8.1.1, we now say:

"When a non-relevant form control changes to being relevant [...]
  [t]he following events must be dispatched to the form control:
  xforms-enabled, xforms-value-changed [...]."

So a control which was previously invisible and may not even ever have
had a value does fire xforms-value-changed and the MIP events.

A parallel could be drawn between this situation and the initial
building of the UI and repeat iterations being added.

This said, not even considering xforms-value-"changed", what about a
form that wants to determine the initial value of MIPs based on
events? This is not possible at the moment.

One use case for this is the "error summary" functionality, which
displays to the user the list of invalid controls at the top of the
page, and can be implemented entirely with events, except for the
issue of determining the initial state of a control's validity.

So even if we decide *not* firing xforms-value-changed upon
initialization, what about firing the MIP events? This would satisfy
the "error summary" use case, and the events are not called *-changed,
so we don't have a terminology issue.

2. What to do upon instance replacement
---------------------------------------

 > I agree that *something* needs to be done about instance node
 > replacement, but I believe this is a minor oversight in
 > xforms-refresh handling that should be corrected.

 > I interpret bullet point 2 as being applicable in the case where the
 > UI binding points to a different node. Note that this should occur
 > whether or not the literal value has changed because the node
 > containing the value has changed, i.e. it is a different string even
 > if it contains the same lexical value.  I am open to any
 > wordsmithing the group feels is necessary to achieve the effect, but
 > this bullet point is definitely the place to fix the instance
 > replacement problem.

I personally don't read much in there that hints at an interpretation
supporting node replacement ;-) So I think it come down to what we
think refresh should do upong instance replacement, and it seems that
we agree it should do something rather than nothing.

One issue to consider is that refresh is based on nodes having been
"marked" for change, instead of controls themselves comparing their
old value with their new value.

Now, during instance replacement, the whole structure of an instance
can change, and the entire instance can be changed, which means that
during refresh a control will be bound to a completely new node
recently created by parsing the document returned by the submission.

A simple but coarse solution would be to mark all nodes of the new
instance has having changed. This will cause all control bound to
nodes of the replaced instance to send xforms-value-changed
events. This is what we do in Orbeon Forms at the moment, pending
something better.

This may not be considered optimal because a control's value may
actually not change upon instance replacement (i.e. it may point to a
new node but containing the same value).

On the other hand, this is already possible now in XForms if a control
changes value multiple times between refreshes: it will be marked for
xforms-value-changed, even if from the user's point of view the value
of the control hasn't actually changed between the two UI refreshes.

Fixing this part would mean drastically changing the way we do
refresh, and I doubt we would want to do this now.

So is there an alternative now to marking every node for dispatching
xforms-value-changed during instance replacement?

 > Finally note that if a control binding to a new node created by
 > instance replacement implies that we consider its value to have
 > changed, then bullet point 3 gives us the fact that it will get
 > events for all the MIPs too.

This is good.

 > This is why I think it is just an oversight in xforms-refresh and
 > not something that should cause us to perform a more major surgery
 > on the event lifecycle.  For example, dispatching the events on UI
 > initialization would mean that alerts for invalid content would fire
 > on startup, which is not the intent.

I think it depends on how an alert is represented. If you load an
instance from a database, and the instance is invalid (use case: work
in progress persisted during a previous session), you would like the
user to see what fields are valid or invalid.

-Erik

-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

Received on Wednesday, 30 May 2007 18:43:34 UTC