Opened 19 years ago

Closed 17 years ago

Last modified 3 years 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

Description

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:

admin.6newslawrence.com/validate_field/polls/polls/question/?value=blah

(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 18 years ago.
atch.xls (13.5 KB ) - added by anonymous 17 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 by gomo@…, 19 years ago

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 by anonymous, 18 years ago

adsadsad

comment:3 by Here, 18 years ago

Type: enhancement

comment:4 by anonymous, 18 years ago

Type: defect

comment:5 by anonymous, 18 years ago

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

comment:6 by vini.reis@…, 18 years ago

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

comment:7 by Adrian Holovaty, 18 years ago

priority: highestlowest
Severity: blockerminor
Type: defectenhancement

by anonymous, 18 years ago

Attachment: email.txt added

by anonymous, 17 years ago

Attachment: atch.xls added

comment:8 by (none), 17 years ago

Milestone Version 1.1 deleted

comment:9 by Simon G. <dev@…>, 17 years ago

Keywords: validators added
Triage Stage: UnreviewedDesign decision needed

comment:10 by tbarta@…, 17 years ago

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 by Jacob, 17 years ago

Resolution: wontfix
Status: newclosed

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

comment:12 by anonymous, 11 years ago

Easy pickings: unset
UI/UX: unset

comment:13 by Jacob Rief, 3 years ago

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