Solution Re: XForms problem

The XForms working group recently published an erratum that will help you 
(the 1.0 second edition spec
is in the W3C publication process now).

The 1.0 spec said that if the nodeset of a delete was empty, the delete 
action would no-op.  The intent,
not stated, was that insert would have the analogous behavior for 
consistency.  The new version of the
spec states this.

The upshot, though, is that XPath predicates can be used to perform 
conditional insertion.

A 'best practice' approach to designing repeat structures in XForms 1.0 is 
to omit the last node of the nodeset
from the repeat, so that it can be used as the prototypical row.  For 
example,  nodeset="blah/blah/row[position()!=last()]"
should appear as the nodeset binding of the repeat.

If you want your repeat to start out empty, then it will by virtue of this 
setting.  Since the user has no
controls to access the data, it won't change.

If you want the repeat to start out with one empty row of data, then use 
an xforms-model-construct-done event
to "conditionally" insert a new row of data if there is the one 
prototypical row (insert nodeset="blah/blah/row[last()='1']")

If you want to omit the prototypical row from the final submitted data, 
use a bind to make it non-relevant.

If you wanted to start with a one row table, then chances are you want to 
get back to a one row table when
the user deletes the last visible row of the table.  Because the repeat is 
not showing the prototypical row of
data, deleting the last visible row has not deleted the prototype. 
Therefore, after your delete action, you can
run a conditional insert to add back a single empty row.  It's the same 
trick we did in xforms-model-construct-done.

The key issue here is that this methodology works for every repeat table 
regardless of the data it is processing.
The method also extends to nested repeats in a straightforward fashion. 

The only issue we have encountered is the following:  if you do a repeat 
in which each row has a delete trigger,
AND you want the repeat to be able to become empty (i.e. you don't enforce 
the existence of a single empty
row in the manner described above), then the result of a deletion loses 
the focus if the last visible row is deleted.
This is because XForms does not support conditionally setting the focus to 
something other than the repeat when
the last row of the repeat disappears.  To alleviate this problem, every 
delete in the trigger would have to be 
followed by an unconditional setfocus to a visible control. 

For this reason, I hope to encourage the inclusion of attribute value 
templates on the attributes of certain XForms elements. 
As I see it, the most important ones are the

action of a submission, e.g. action="{xpath expression resulting in URI}" 
the control of a setfocus action, e.g. control="{xpath expression 
resulting in ID}"
the case of a toggle action, e.g. case="{xpath expression resulting in 
ID}"

Best regards

John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/





Vincent Berger <vincent.berger@afp.com> 
Sent by: www-forms-request@w3.org
08/23/2005 05:13 AM

To
Allan Beaufour <abeaufour@novell.com>, www-forms@w3.org
cc

Subject
Re: XForms problem






Le mardi 23 août 2005 à 13:45 +0200, Allan Beaufour a écrit : 

Tuesday 23 August 2005 12:05 skrev Vincent Berger:
> Le mardi 23 août 2005 à 16:16 +0700, Saran Toochinda a écrit :
> > We're planning to use XForms to collect XML data (currently using 
Novell
> > XForms Explorer for IE). The data we're collecting is company data, 1
> > file per company. The schema is change from time to time which most of
> > the time is resulting in newly added data elements. The XForms 
controls
> > need to be added accordingly to accept the new data elements. There is 
no
> > problem on new file data entry so far but the problem arise when 
dealing
> > with existing files. Because Xforms' controls bind to existance of
> > element in an instance document. The newly added controls don't get
> > display because no such data ever exists before. Do I missing 
something?
> >
> > One other issue is about repeat control. Usually we provide a trigger 
to
> > insert and delete repeated element. Once we delete all elements, we 
have
> > way(s) to insert it back again?
>
> About repeat control, I keep an element in a section (called in an
> arbitrary way)  "<patterns>" ,
> and use the xforms function "duplicate" when I want to populate an empty
> "container".

Unfortunately duplicate is an XForms 1.1 control.


Yes, but is working , in this case, on Novell Xforms Explorer for IE, as 
specified by Saran.




-- 
Vincent Berger <vincent.berger@afp.com>
Agence France-Presse 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 

This e-mail, and any file transmitted with it, is confidential and 
intended solely for the use of the individ ual or entity to whom it is 
addressed. If you have received this email in error, please contact the 
sende r and delete the email from your system. If you are not the named 
addressee you should not disseminate, distr ibute or copy this email. 

For more information on Agence France-Presse, please visit our web site at 
http://www.afp.com 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-