Re: Allow xf:setfocus with no @control to set the focus to the event target

John,

I think you make a convincing case.

As a side note I don't think that not sending xforms-invalid when the  
value (and its validity) has not changed is a quirk, rather it is a  
very desirable feature.

-Erik

On Aug 26, 2008, at 4:25 PM, John Boyer wrote:

>
> Hi Mark,
>
> I'd like to understand whether the example of keeping the focus on a  
> control if it is filled out incorrectly really works as a technique.
>
> One problem is that filling out one field incorrectly may cause  
> multiple controls to receive xforms-invalid events, and they will  
> arrive in an undefined order, so there is no way to guarantee that  
> the focus will stay in "the" invalid control.  Could work for simple  
> forms with few data dependencies, but is not generally applicable.
>
> A second problem is that the invalidity in one control may be the  
> fault of a bad data entered elsewhere.  The user may want to leave  
> the invalid data but then go fix the real problem.  For example,  
> suppose the user with a bachelor's degree is asked to enter his age  
> and he types 18 rather than 28.  A simple typo.  Then, when asked  
> for years of schooling, the user enters 20.  This pops a constraint  
> because he can't have more years of education than he has years of  
> life.  However, the problem is with the age data, not the education  
> data.
>
> For the above reason, and just generally speaking, it is usually  
> considered to be poor UX to freeze up the focus in an invalid  
> control.  The better practice is to stop the first focus out, but  
> then let the second attempt to remove focus succeed if the user has  
> made no changes.  Now it turns out that a quirk of our processing  
> model might actually make an "event target setfocus" do exactly this  
> behavior because a second tab would not change the value, so you  
> would not get another invalid event.  To be clear, if you have this
>
> <input ref="age" id="X">
>    <label>Age</label>
>    <setfocus ev:event="xforms-invalid" control="X"/>
>   <alert>Please enter an integer number.</alert>
> </input>
>
> then if the user types "abc" and hits tab, then the focus would stay  
> in the control and the user would see the alert.  But if the user  
> hits tab again, then no data has changed so I don't think another  
> xforms-invalid event would occur, which means the focus would move  
> on, right?
>
> If so, is this the same as "preventing the user from leaving the  
> control if its value is not set appropriately"?
>
> And regardless of how this discussion goes, I don't really  
> understand why using the event function would look weird.
>
> <setfocus ev:event="xforms-invalid">
>      <control value="event('target')"/>
> </setfocus>
>
> It seems to say enough that it is clear what is going on.  Put  
> another way, even if we chose a default of event target, I don't  
> think the method is declarative until you have a way to explicitly  
> state the default, so it would still be necessary to have a way of  
> saying that the control to focus is given by the event target.
>
> 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
>
>
>
>
> From:
> "Mark Birbeck" <mark.birbeck@webbackplane.com>
> To:
> John Boyer/CanWest/IBM@IBMCA
> Cc:
> "Ulrich Nicolas Lissé" <unl@dreamlab.net>, public-forms <public-forms@w3.org 
> >
> Date:
> 08/20/2008 06:56 PM
> Subject:
> Re: Allow xf:setfocus with no @control to set the focus to the event  
> target
>
>
>
>
>
> Hi John,
>
> > [snip]
> >
> > Does it really make sense to try to focus the event target?
>
> If that's what the author wants...yes. It's not uncommon in HTML forms
> to prevent users from leaving a control if its value is not set
> appropriately, for example.
>
>
> >  What if a
> > sequence of actions is grouped together and invoked from multiple  
> locations
> > using dispatch?
>
> Sure...but if the listener is on the control, then you'll always
> ultimately get Event.target set to the control in question, won't you?
>
>
> > It seems an odd thing to see <setfocus/> without any indication of  
> what the
> > focus is being set to.
>
> No different to any other default values, surely? (xf:rebuild,
> xf:refresh, xf:submit, xf:send, etc.) And a lot less weird looking
> than using the event() function. :)
>
> Regards,
>
> Mark
>
> -- 
> Mark Birbeck, webBackplane
>
> mark.birbeck@webBackplane.com
>
> http://webBackplane.com/mark-birbeck
>
> webBackplane is a trading name of Backplane Ltd. (company number
> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> London, EC2A 4RR)
>
>
>

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

Received on Wednesday, 27 August 2008 06:25:28 UTC