Opened 17 years ago

Closed 15 years ago

Last modified 15 months ago

#19 closed enhancement (wontfix)

Automatically generate JavaScript form validation

Reported by: Adrian Holovaty Owned by: Adrian Holovaty
Component: Validators Version: new-admin
Severity: minor Keywords: validators
Cc: tbarta@…, Jacob Rief Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Django should generate JavaScript form validation for all admin pages, in addition to the server-side validation it already does.

Each FormField object already gets an HTML class of the type of field it is (e.g. "vCheckboxField", "vEmailField", "vTextField"), so we can probably build off of that.

OR, we could use XMLHttpRequest to send each field individually and validate everything *server-side*.


I've given some more thought to this. We could set up a view that validates a given field via XMLHttpRequest, like this:

(The "value=blah" would be POST data, not GET data.)

But here's a problem: What do we do for validators that expect all_data, i.e. the ones that validate a field according to the value of another field? We could solve that by only using dynamic JavaScript? validation to check single fields and using server-side validation for the rest -- but it's a usability problem if some validation errors appear instantly and others appear after form submission.

Attachments (2)

email.txt (1.5 KB) - added by anonymous 16 years ago.
atch.xls (13.5 KB) - added by anonymous 16 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 17 years ago by gomo@…

I think it's feasible to do a mixed checking here. I assume somewhere along the code there is a definition for every validator. What should be done is add to that definition a string attribute containing the JS function used to validate server-side. Then, simply, if this attribute is not present, do the check server-side. An existing library like Sajax could be used for this. Chained validations involving more than one field wouldn't be as simple but it's still doable. And all this should be done using unobtrusive JS so that users that don't support client-side validation get the traditional HTML errors upon posting the page.
I can help with this, I have ported Sajax to mod_python (it's a really simple library) and I can write JS too. Just let me know.

comment:2 Changed 16 years ago by anonymous


comment:3 Changed 16 years ago by Here

Type: enhancement

comment:4 Changed 16 years ago by anonymous

Type: defect

comment:5 Changed 16 years ago by anonymous

Component: Admin interfaceValidators
milestone: Version 1.1
priority: lowesthighest
Severity: normalblocker
Version: new-admin

comment:6 Changed 16 years ago by vini.reis@…

Which will be the benefits of using XMLHttpRequest to validate form data?
Why not just use common javascript validation code?

comment:7 Changed 16 years ago by Adrian Holovaty

priority: highestlowest
Severity: blockerminor
Type: defectenhancement

Changed 16 years ago by anonymous

Attachment: email.txt added

Changed 16 years ago by anonymous

Attachment: atch.xls added

comment:8 Changed 16 years ago by (none)

Milestone Version 1.1 deleted

comment:9 Changed 16 years ago by Simon G. <dev@…>

Keywords: validators added
Triage Stage: UnreviewedDesign decision needed

comment:10 Changed 15 years ago by tbarta@…

Cc: tbarta@… added

vini.reis: The benefit of using server-side validation in general is twofold:

  • Code duplication is reduced. Something doesn't have to be written in both Python and Javascript in order to work.
  • Some inputs may not be validatable client-side (e.g. validating that a Latitude/Longitude coordinate was over land and not over water, which would require a GIS database).

That being said, there are certainly issues with server-side validation:

  • A lot more traffic for the XmlHttpRequests that could have been addressed entirely at the client.
  • Multi-input validation either wouldn't get done, or would have to be triggered on all changes.

I am not familiar with Django's admin interface, but something like this would be quite useful in any Django-powered application, so it could be worth developing generically.

comment:11 Changed 15 years ago by Jacob

Resolution: wontfix
Status: newclosed

For now this isn't worth thinking about. WONTFIX.

comment:12 Changed 10 years ago by anonymous

Easy pickings: unset
UI/UX: unset

comment:13 Changed 15 months ago by Jacob Rief

Cc: Jacob Rief added
Note: See TracTickets for help on using tickets.
Back to Top