Opened 7 years ago

Closed 4 years ago

#15250 closed enhancement (patchwelcome)

request for a way to detect / run code after a dijit.form.Form has been completely reset

Reported by: richso Owned by:
Priority: undecided Milestone: 1.13
Component: Dijit - Form Version: 1.7.2
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

this is a request for a way to detect / run code after a dijit.form.Form has been completely reset and no more relevant onChange events will be triggered which is very essential when implementing forms doing AJAX actions for e.g. editing / adding records, something like this is useful:

dojo.connect(dijit.byId('form'), 'onAfterReset', function(evt){
   // assume no more relevant onChange event will be triggered by the previous reset
   // change the state of the save and cancel buttons, e.g.
   dijit.byId('btnSave').set('disabled', true);
   dijit.byId('btnCancel').set('disabled', false);
});

Change History (9)

comment:1 Changed 7 years ago by richso

OR a method / mechanism to disable the generating of events to the form elements and a method to enable it back (like the Delphi way).

comment:2 Changed 7 years ago by bill

Are talking about a Form.reset() call? If so, seems like it should return a Promise. It also seems like it shouldn't generate any onChange events, although I suppose that's debatable. (I'm also not sure if you are talking about events from the Form itself, or from it's child widgets.)

If you are talking about the initial instantiation of the form, seems like that shouldn't fire any onChange events.

Or, are you talking about a third thing?

comment:3 Changed 7 years ago by Douglas Hays

If I understand the request, Form.reset() and Form.set('value',...) would have to return a Promise that was tied to individual child widget's onChange processing which would also need to be enhanced to work with Promises. But I'm not sure I agree with this idea since the child widget values have been changed before onChange fires and thus the Form reset/set has completed before onChange events fire.

comment:4 Changed 7 years ago by richso

so my alternative suggestion is to implement a mechanism / pair of methods for disabling and enabling the form elements from generating change events, like Delphi that have a method called form.disableControls / form.enableControls (as I recognized); by using this pair of methods we can set the values / states of the form elements to prepare for next round of editing in between them without triggering the complex events cycle, use like this:

form.disableControls();
set the form elements with record field values of next record; no onChange event will be generated
disable save button
change cancel button label to "close"
form.enableControls(); the form elements will then response to new changes only

Note: using a similar approach in the reset() method may prevent from dealing with the complex events cycle

comment:5 Changed 7 years ago by Douglas Hays

That sounds like a wrapper API to the currently private widget._onChangeActive boolean that does just that but on a per widget basis.

comment:6 Changed 7 years ago by bill

Description: modified (diff)

What if Form.set(...), which calls set() on the child widgets, used that third parameter to set() to turn off notifications?

childWidget1.set("value", 123, false);
childWidget2.set("value", "hello world", false);
...

Form could still send it's own onChange() notification.

comment:7 Changed 6 years ago by Douglas Hays

Owner: Douglas Hays deleted
Status: newassigned

comment:8 Changed 6 years ago by Douglas Hays

Status: assignedopen

comment:9 Changed 4 years ago by dylan

Milestone: tbd1.12
Resolution: patchwelcome
Status: openclosed

Given that no one has shown interest in creating a patch in the past 3+ years, I'm closing this as patchwelcome.

Note: See TracTickets for help on using tickets.