#7124 closed (wontfix)
Form field javascript event handler
Reported by: | Mihai Damian | Owned by: | nobody |
---|---|---|---|
Component: | Forms | Version: | dev |
Severity: | Keywords: | ||
Cc: | 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
This is a feature request.
Wouldn't it be nice if newforms fields could have a javascript event handler attribute (onChange,onFocus,etc.)?
There is a workaround that involves programaticaly binding the handlers from a javascript function that's called on page load. However, having the handlers declaration generated together with the input elements seems more natural.
Change History (7)
comment:1 by , 17 years ago
comment:2 by , 16 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
comment:3 by , 16 years ago
my 2 cents here: the javascript event handler can be part of the presentation layer (e.g. eyecandy) OR the application (e.g. validation) here, so it should be possible to add the event handler in the template OR in the view code.
comment:4 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
The "workaround" mentioned is the way that most modern javascript toolkits work (and similar to how Django's admin widgets work). The "unobtrusive javascript" they support is superior to inline event handlers in many ways, but especially when you come to needing more than one event handler. Encouraging this way of programming seems like a step backwards, especially as it means you will have multiple places to look for finding javascript. Using most toolkits, you would be able to hook up the event handlers by adding a bit of javascript code into your template with very little code, e.g. jQuery:
jQuery(function(event) { // this function will run when the document is ready $("id_email").change(function () { // this will run when input with id = "id_email" is changed. // do something here }); });
Since you can already add the "onchange" etc attributes if you really want to (using "attrs" as mentioned above), I'm closing as WONTFIX.
comment:5 by , 16 years ago
i absolutely agree with you that dynamically attaching event handlers *should* be the way to go in most cases - BUT: on some lightweight client devices e.g. mobile phones, traversing the DOM with jquery et al can be prohibitively expensive for more complex documents (e.g. 5 sec ui freeze on iphone for a html doc with a 300 elements). while in these cases the workaround as pointed out by you can be applied, defining the event handler is clearly a task of the frontend designer (at least in our workflow) so it should be possible to do it in the template.
i can absolutely understand that there are more important things to do, but just wanted to provide a real-life usecase for this request for the record.
comment:6 by , 16 years ago
My example should have been $("#id_email")
of course, which I'm sure jQuery will optimise into a simple document.getElementById()
without doing any DOM traversal. Or you can do this yourself, without the jQuery dependence. Either way, I'm sure it can't take 5 sec no matter the size of the document. If you want designers to be able to do this by just editing templates, your options are:
- Use the above method of adding event handlers using
document.getElementById()
(or some wrapper, like jQuery). - Don't use Django to render the entire form -- render it field by field in the template, overriding with custom HTML as necessary.
- Some complex template tag that allows you to add "onchange" handlers to a form field from within the template. This would likely be very messy, and not actually designer friendly.
This discussion is straying from the feature request first given in the bug, of course -- adding event handler attributes in Python code is already supported by attrs
, and won't help your use case. If you have a more concrete suggestion about how to better support adding event handlers in the template, it would be best to open another ticket.
comment:7 by , 16 years ago
ok, i'm convinced now :) - i was carried away by my experience with generic CSS-selector-based behaviors, so i missed that obvious simpler and indeed optimizable case. sorry for the noise...
Django provide attrs in constructor of fields. Technically onchange event should be written over there. But it is not putting onchange in HTML.