Does anyone has any thoughts about starting a project to simplify client-side form validation and input? I started thinking about this because I think date input in most web applications is broken. I really like Simon Willison''s demo: http://simon.incutio.com/code/js/date-parser/ I think this could be improved (by mapping say shift+left-arrow to the previous day, and shift+up-arrow to the previous month) and extended to deal with even more specific cases, or the time of the day. I think that this script, with some other helper/validation tools, would make a pretty sweet package. Thoughts? Ideas? Thank you, Beau
On Monday 08 August 2005 19:15, Beau Hartshorne wrote:> Does anyone has any thoughts about starting a project to simplify ? > client-side form validation and input?Yes, I have thoughts on this topic... http://www.schuerig.de/michael/javascript/index.html#id2482756 There''s no documentation, have a look at the unit tests to get an idea. Michael -- Michael Schuerig The Fifth Rider of the Apocalypse mailto:michael@schuerig.de is a programmer. http://www.schuerig.de/michael/
I saw a good one on particle tree a few days ago, unobtrusiive JS validation. Rules are defined either by hidden fields, class=".." entries or in the HTML tag after changing the DTD. Cool thing about it is that all the validation stuff is added to the HTML code dynamically, by the JS itself. Would describe more but hungover - look it up on particle tree. They also have AJAX variant. Quite nifty as to implement it I just need to change one class in our servlets and then include a JS file in the page.
Here is the URL of the article I mentioned in my reply: http://particletree.com/features/a-guide-to-unobtrusive-javascript It seems to be very elegant way of handling the validation, and certainly is quick to implement. The code is straight forward and its quite easy to add your own custom validators. The only problem I can see is choosing which method to use to define validation rules, using a custom DTD is quite cool, but I can see how that may confuse browsers and probably not best coding practise. I like the idea of putting the rules in CSS classes, but that may confuse people looking at the code. I will say that it is dead easy to implement, our apps have a servlet backend using MVC approach, a simple change to the class which generates text boxes and the inclusion of the JS file was all that we had to do to get it working. Back to work Chris
I think putting the rules in the CSS classes is the cleanest design, and best follows the guidelines recommended over at WASP: http://domscripting.webstandards.org/?page_id=2 My intent here is to build a set of shared widgets that make form input easier and more user friendly. Validation is really just an added benefit. Ideally, we should only need to define validation rules once in Rails (DRY!), and then link those rules to actual client-side scripts that enforce them. If JavaScript is circumvented or disabled, the Rails rules will still enforce validation at the server side, but I think it would be great to see some magic that makes this scripting transparent as well. (This is where I''m over my head. I haven''t built a production Rails app yet, but am about to.) I think an obviously broken form task is date entry. I don''t like calendars or drop downs to select dates, I find most people can type much faster than they click around these tiny boxes a mouse. Other helpful tools could be simple things like a Caps Lock icon when users are entering passwords: http://www.howtocreate.co.uk/jslibs/otherdemo.html#cld How many of you do not live in the US, and have had to find your country in some huge list? Why not just let users type it in, and guess/validate against a known country list? Broken. So ideally, if the script found a <input type="password" />, it would know to display the caps lock warning in the field. If the script found <input type="text" class="validDate required" />, it would know to treat that field as a required date, and know how to validate that properly. Same with class="validCountry required". The obvious benefit of using CSS classes here is that the required class can also be assigned a style to show visually that the element is required. What else is broken? How can this functionality be tightly and transparently integrated with Rails? Thanks, Beau On 9-Aug-05, at 8:44 AM, Chris Korhonen wrote:> Here is the URL of the article I mentioned in my reply: > > http://particletree.com/features/a-guide-to-unobtrusive-javascript > > It seems to be very elegant way of handling the validation, and > certainly is quick to implement. The code is straight forward and its > quite easy to add your own custom validators. The only problem I can > see is choosing which method to use to define validation rules, using > a custom DTD is quite cool, but I can see how that may confuse > browsers and probably not best coding practise. I like the idea of > putting the rules in CSS classes, but that may confuse people looking > at the code. > > I will say that it is dead easy to implement, our apps have a servlet > backend using MVC approach, a simple change to the class which > generates text boxes and the inclusion of the JS file was all that we > had to do to get it working.
> makes this scripting transparent as well. (This is where I''m over my > head. I haven''t built a production Rails app yet, but am about to.)Not actually got around to trying Rails yet, glanced at the site but not downloaded yet. Can you recommend any hosting packages? Is it suited for applications where you are interfacing with external Web Services etc.> I think an obviously broken form task is date entry. I don''t like > calendars or drop downs to select dates, I find most people can type > much faster than they click around these tiny boxes a mouse.I was reading the WebForm 2.0 spec the other day, seemed to include a fair bit of date/time support. Of course it will probably not be seeing the light of day anytime soon. As far as date entry goes, we got some usability analysis done for us a while back, and one of the reccomendations was to replace all of our YY/MM dropdowns with text boxes, so for that use then definately faster, though if for example you are selecting a date for a travel booking, it is sometimes nice to have a popup calender.> How many of you do not live in the US, and have had to find your > country in some huge list? Why not just let users type it in, and > guess/validate against a known country list? Broken.Thats a good one, and fairly simple to do. Nice simple AJAX autocomplete.> So ideally, if the script found a <input type="password" />, it would > know to display the caps lock warning in the field. If the script > found <input type="text" class="validDate required" />, it would know > to treat that field as a required date, and know how to validate that > properly. Same with class="validCountry required". The obvious > benefit of using CSS classes here is that the required class can also > be assigned a style to show visually that the element is required.It should be fairly straight forward to take the tutorial and modify it to achieve that kind of behavior, though I''m not sure if the password thing would work unless the user has already started typing. It seems to be more of a feature a web browser should offer....> What else is broken? How can this functionality be tightly and > transparently integrated with Rails?One thing I did like, which I saw the other day, was a slider object for a webform. Using JS you could make a wide range of ''cool'' minput widgets, the only thing you need to be aware of is usability - no point in trying to fix something if it aint broken. The other key thing is to ensure it can easily be integrated, thats why I love this technique of attatching all the listeners and event handlers at runtime, client-side. Programmers dont have to worry about anything.
On 09/08/05, Chris Korhonen <ckorhonen@gmail.com> wrote:> As far as date entry goes, we got some usability analysis done for us > a while back, and one of the reccomendations was to replace all of our > YY/MM dropdowns with text boxes, so for that use then definately > faster, though if for example you are selecting a date for a travel > booking, it is sometimes nice to have a popup calender.The one doesn''t preclude the other. Make text input fields and a popup calender as an alternative way to insert a date into these input fields. Bye, Martin
On 09/08/05, Beau Hartshorne <hartshorne@gmail.com> wrote:> My intent here is to build a set of shared widgets that make form > input easier and more user friendly. Validation is really just an > added benefit. Ideally, we should only need to define validation > rules once in Rails (DRY!), and then link those rules to actual > client-side scripts that enforce them. If JavaScript is circumvented > or disabled, the Rails rules will still enforce validation at the > server side, but I think it would be great to see some magic that > makes this scripting transparent as well.I do all validation server-side, although also during data entry via AJAX. No duplication of validator-code, easier to manage, no danger of divergence between client-side and server-side validation results. But the code is written in PHP, and not a condition to be used as a general framework. Bye, Martin