Re: AjaxObserveField mandatory input fields

Hi René,

Growling in general is a good trick to have up your sleeve. It may, or  
may not, be what you want here but it sounds like it could be.

There are several frameworks out there. I've used "Qutensil" before:

https://github.com/bulckens/Q.js

When you "growl" you don't have to worry about where it is displayed.  
It just appears and floats up to the top of the page. They can stack  
too. They can disappear after a few seconds or you can make them so  
you have to manually close them. Also handy for just confirming that  
you did something successfully.
AARON ROSENZWEIG / Chat 'n Bike
e:  [email protected]  t:  (301) 956-2319 	
	

On Mar 4, 2013, at 2:02 PM, René Bock wrote:

> Hi Aaron,
>
> thanks for your quick answer...
>
>
> Am 04.03.2013 um 17:55 schrieb Aaron Rosenzweig <[email protected] 
> >:
>
>> Hi René,
>>
>> The observeField is only fired on an "onChange" event. What you are  
>> asking for is "onBlur" but only when the value is null.
>>
>> My guess is you'd be better served not trying to modify  
>> AjaxObserveField but instead write a custom handler in javascript  
>> to handle this particular case.
>
>
> Agreed :-)
>
>>
>> When you know that the value is wrong right there on the client  
>> side, there is no need to round trip to the server for a partial  
>> page refresh.
>
>
> I leave this "optimization" for a future release of our openforms  
> frameworks ;-)
>
>
>>
>> I don't know your use case exactly but if this is heads down data  
>> entry... perhaps force them to stay on the field when they "tab"  
>> and then "growl" a message in screen. Allow them to "click" with  
>> the mouse and leave but then growl again. Or if that is still too  
>> draconian just growl but allow them to tab off.
>
>
> The latter would be ok
>>
>> I've done some variant of this when the need arose but I wouldn't  
>> say this is a common occurrence. I think most people are aiming for  
>> regular "joe" users doing signups (not hard core salaried data  
>> entry folks).
>
> Are there any statistics around, about regular "joe" users knowing  
> how step through forms by using the "tab" key?
>
>> For regular joe users I'd think you'd want them to fill out as much  
>> as possible and if you really must force a response on that field  
>> show them an error before going to the next step of the wizard.
>
> The task I working currently on is to give the user feedback as soon  
> as possible on the input he gave (or not gave).
>
>>
>> I'd like to point out one other thing... Perhaps your update  
>> container should only be around the error message bucket. As it is  
>> now... if there were multiple fields inside the update container...  
>> one could NOT do hardcore data entry. Trying to do so would be  
>> frustrating as it is constantly refreshing and you'd get caught in  
>> the middle of typing the next value... especially over slow  
>> connections. Not cool! :-)
>
> No, there will be only one input field per Update-Container.  But  
> there will be many UpdateContainer on a page.
>
>>
>> Consider something like this:
>>
>> < AjaxUpdateContainer id="errorContainerID">
>> 	<if condition = errorsExist>
>> 		<displayErrors />
>> 	</if>
>> </AjaxUpdateContainer>
>>
>>  < AjaxObserveField updateContainerID="errorContainerID">
>> 	<WOTextField  value = firstName/>
>> 	<WOTextField  value = lastName/>
>> 	<WOTextField  value = email/>
>> </AjaxObserveField>
>
>
> The forms our customer build with our tool tend to be "longish".  So  
> the error message should appear near the Input fields.
>
>>
>> Anyway... you are right... when you need something hard core you  
>> can't just do it with the Ajax framework. It gets you 80% there but  
>> for your additional validation you need to add custom javascript.
>
> But it's essential to check, if a feature belongs to 80% given or to  
> the other 20%  :-)
>
> On the other side, I'm very pleased about easy it was to integrate  
> the ajax functionality into our existing frameworks.  Validation is  
> not the only challenge...
>
>
>> Note: Notice how one observe field wraps multiple fields and  
>> doesn't need to use "observeID" bindings.
>
> I imagined this after reading the implementation of the observer...
>
>>
>> On Mar 4, 2013, at 11:06 AM, René Bock wrote:
>>
>>> Hi all,
>>>
>>> I'm using a combination of AjaxObserveField and  
>>> AjaxUpdateContainer to perform input validation and to display the  
>>> appropriate error messages. E.g
>>>
>>> < AjaxUpdateContainer id="foo">
>>>
>>> 	<WOTextField  id="bar"/>
>>>        < AjaxObserveField observeFieldID="bar"  
>>> updateContainerID="foo">
>>>
>>> 	<if condition = bar_has_invalid_value>
>>> 		<displayErrors />
>>> 	</if>
>>>
>>> </AjaxUpdateContainer>
>>>
>>>
>>>
>>> Usually, an AjaxObserveField will trigger an UpdateContainer only  
>>> when the value of the observed field changes . The above construct  
>>> works for me in all cases but one:
>>>
>>>
>>> Let "bar" be a mandatory field.  When the user sets the input  
>>> focus to the field and leaves the field without setting any value,  
>>> the AjaxObserveField won't fire and no error message will be  
>>> displayed :-(
>>>
>>>
>>> My first attempt to solve this, would be do to add a class  
>>> "mandatory" to "bar" and change the behavior of AjaxObserveField to
>>>
>>> 	fire if the bar.value has changed OR  bar.class contains  
>>> "mandatory" and bar.value is null
>>>
>>>
>>> Now: is the there already a hook in AjaxObserveField  to implement  
>>> this or what would be the recommendet way to enhance  
>>> AjaxObserveField in order to handle this (I guess not so uncommon)  
>>> use case?
>>>
>>> Any (other) hints are welcome!
>>>
>>>
>
>
>
>
> regards,
>
> René Bock
> Software Engineering
>
> --
> salient doremus
> http://www.salient.de				http://www.openforms.de
>

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb

_______________________________________________
Wonder-disc mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wonder-disc