Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Dynamically bind changed handler on custom component creation

    Hello,

    We are trying to create a dynamic form which when the user enters a value, a change handler is triggered to then save that value via some custom logic. The below code shows a basic example of what is trying to be done:

    Code:
    isc.ClassFactory.defineClass("CustomForm", "DynamicForm").addProperties({
    initWidget: function(){this.Super('initWidget'); if(this.addChangeHandler) {this.getField('timeField').changed = alert('Saving form...');}}
    });
    
    isc.CustomForm.create({
        ID: "timeForm",
        numCols: 4,    
        width: 650,
        addChangeHandler: true,
        fields: [
            {name:"timeField", title:"Input time", type:"time", wrapTitle:false}
    ]
    });
    All the initialisation code, including the binding of the change handlers, should logically go into the initWidget method, but there is a slight complication in that some components such as TimeItem uses the FormItem.setValue() api to set the default value (or at least that seems to be the case from the browser tools call stack) on component creation, which then triggers the change handler incorrectly, causing the form to persist (via the handle method) with the default value.

    In the above example, we would want the entirety of the CustomForm.create() call to execute without triggerring the changed method.

    What would be the recommended way of hooking into the component creation lifecycle to accomplish this?

    As a shortcut, we have currently split out a separate method to bind the change handlers but would ideally like to put that logic into the initWidget method body.

    #2
    If changed is firing on creation that would be a bug, however, first, your approach isn't valid: you can either add a changed handler after a FormItem has been created, via addMethods() (not direct assignment) or you can modify the fields data before calling Super, using direct assignment at that point.

    If that still triggers the problem, make sure you are using the latest patched version, and let us know what edition and version of the product you're using.

    Also, even if changed() erroneously fires, a simple workaround would be to ignore any such firing until after draw().

    Finally, you might be reinventing a feature that's already part of the framework - see DynamicForm.implicitSave.

    Comment

    Working...
    X