Re: validity notification on intial or hidden data

Hi Jaroslav,

Some answers are inline, surrounded by <jb> </jb>

Cheers,
John M. Boyer, Ph.D.
Senior Technical Staff Member
Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





Jaroslav Pullmann <pullmann@doctronic.de> 
Sent by: www-forms-request@w3.org
05/14/2008 04:08 AM

To
www-forms@w3.org
cc

Subject
validity notification on intial or hidden data







  Dear list contributors,

   in a recent post (
http://lists.w3.org/Archives/Public/www-forms/2008Apr/0004.html)
   the request was mentioned to apply standard form control notification 
events upon
   initialization of form controls. Could you please clarify shortly -

    - will this request become an official requirement for future XForms 
specs ?

<jb>
It's the top agenda item for next week's telecon.
</jb>

    - is there currently a way to force the validity notification on 
initial data
     (that is not covered by the definition: "an instance data node either 
changing and
     being or becoming invalid") ?

<jb>
Currently, no.  The desire to get notifications on initialization is 
well-known to the group though.  Right now, form control initialization is 
silent. Form controls are expected to initialize themselves according to 
the information of the model without the model dispatching notifications 
to them.  If you think about XForms processing as being divided into 
modules, such as model processing, action processing and UI processing, 
then the UI processor could, in the future, dispatch an event to signal 
control initialization.  The context information for the event could 
contain the bound node and the states of the various MIPs.  But the 
question arises whether this will satisfy the use cases which cause you to 
desire the MIP notification events today. It needs further elaboration 
from the community, so please feel free to describe how you intend to use 
the MIP notification events on startup and why it is insufficient, as an 
alternative. to have your implementation query the model for MIP 
information when it creates a new control.  Finally, note that any 
solution has to work *any time* a UI control is created, not just when 
starting up the form.  In particular, the repeat module creates and 
destroys UI controls often.
</jb>

    - why is the notion of "validity" of a instance node bound to its UI 
control
      and not to the respective node, instance or a bind element referring 
to it ?

<jb>
The notion of validity is _not_ bound to its UI control.  The notion of 
validity is associated with actual instance nodes.  The purpose of the 
model, though, is to inform the UI when things have changed.  When MIPs 
change, or when a value changes, the MIP notification events are sent to 
the controls.

The key to understanding this is to know why the MIP notification events 
exist.  In their current design, they allow *form authors* to discover 
changes with which they may want to associate behaviors.  For example, one 
could run an ephemeral message action when xforms-invalid is received. 
They are not designed currently to serve a second purpose of facilitating 
a particular style of XForms UI processor implementation.  So, currently 
they are meant as an aid to authors, not implementers.  I suspect the 
reason you want the events on startup is that you would like an 
implementation to use the events for some purpose.  Addressing that 
requirement is on the future feature list, but it's not supported right 
now.
</jb>

   Examples: A (required) node is initialized to an invalid value,
   no "xforms-invalid" event is triggered preventing any implicit or
   explicit error recovery or UI adjustment. In contrast the CSS
   pseudo-classes (:valid, :invalid) are effective and allow
   to mark the invalid control.

   Also one would prefer to handle the invalidity of "hidden"
   (calculated) values by the generic means of event handling,
   like registering a handler on the instance or a bind element.

<jb>
The implementation is expected to show the right thing for required and 
validity-related MIPs without need of the event.  The form author only 
hooks the event when something changes.

This design was especially put in place for form authors to have a 
convenient way to handle xforms-invalid in XForms 1.0, which did not 
directly support conditional execution of actions (some actions like 
setvalue, insert and delete could use XPath predicates in their binding 
nodes to hack up some conditional behavior, but other actions like message 
did not define this behavior for simple static messages).

The problem was that an initially empty template would have many nodes 
that were "required but empty", which at the time was included in the 
definition of validity and therefore resulted in an xforms-invalid event. 
The concern was that the user would have a very poor experience if the 
simple act of starting up a form resulted in a ton of xforms-invalid error 
messages informing the user that the form is not correctly filled out. The 
feeling was that the user really needed to get in there and change 
something before being told that they had done something wrong.

Put another way, the attempt to associate xforms-invalid with the :invalid 
pseudoclass is appealing to the implementer, but reduces the utility of 
the event for form authors by interfering with a pleasant user experience.
</jb>


   Many thanks
    Jaro Pullmann




-- 
jaroslav pullmann             d  o  c  t  r  o  n  i  c
email pullmann@doctronic.de   information publishing + retrieval
phone +49 228 92 682 00       http://www.doctronic.de

doctronic GmbH & Co. KG, Sitz: Bonn, HRA 4685 AG Bonn
Ust-IdNr.: DE 210 898 186, Komplementaerin:
doctronic Verwaltungsgesellschaft mbH, Sitz: Bonn, HRB 8926 AG Bonn
Geschaeftsfuehrer: Holger Floerke, Carsten Oberscheid, Ingo Kueper