Code

Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#7124 closed (wontfix)

Form field javascript event handler

Reported by: MihaiD Owned by: nobody
Component: Forms Version: master
Severity: Keywords:
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

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.

Attachments (0)

Change History (7)

comment:1 Changed 6 years ago by anonymous

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Django provide attrs in constructor of fields. Technically onchange event should be written over there. But it is not putting onchange in HTML.

comment:2 Changed 6 years ago by serialx

  • Triage Stage changed from Unreviewed to Design decision needed

comment:3 Changed 5 years ago by ledermann@…

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 Changed 5 years ago by lukeplant

  • Resolution set to wontfix
  • Status changed from new to 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 Changed 5 years ago by anonymous

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 Changed 5 years ago by lukeplant

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 Changed 5 years ago by anonymous

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...

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.