View bindings

[Jacob Emcken]

Hi.

I have bound a form to an atom and I can change values in the form but using swap/reset just fine.
But it I also have som old jQuery code listening for changes on an input field, which doesn't get triggered when changing values in the form through the view binding.

Changing the value of the input field by actually typing in the field still triggers the change event just fine.

Is this functionality missing on the view binding, or am I doing something wrong?


The old code attaching a change listener is:

    $('input[name=zip]').change(function() {
       ...
    });


I have tried triggering the event manually using domina.events/dispatch! but haven't been able to trigger an event which the above jquery catches.


Does anyone have some insight on how that could be done?


--
Cheers
Jacob

[Creighton Kirkendall]

Jacob,

That is a really hard problem.  Since onChange is a browser event its not triggered by javascript setting the value.  This is true in jquery and in enfocus.  To get jquery to fire on onChange you would need actually fire the event on the jquery side.  

(.change (jQuery 'input[name=zip]')) 

CK

--
 
---
You received this message because you are subscribed to the Google Groups "Enfocus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enfocus+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jacob Emcken]

Enfocus (or goog.events?) supports a change event (:change) which I take isn't the same as the jQuery change event.

But would it make sense to trigger that event on the form element which changes?
Then its possible to listen for changes using enfocus (and even firering a jQuery change events using (.change (jQuery (.currentTarget e)))) from there if need be.

--
Cheers
Jacob

[Jacob Emcken]

Hi.

I've tested the following and it works in my use case. I don't know how much overhead it adds that a change event is triggered every time.
But would it make sense to include in enfocus?

    Modified   src/cljs/enfocus/core.cljs
diff --git a/src/cljs/enfocus/core.cljs b/src/cljs/enfocus/core.cljs
index 60b294a..70ff587 100644
--- a/src/cljs/enfocus/core.cljs
+++ b/src/cljs/enfocus/core.cljs
@@ -14,4 +14,5 @@
             [clojure.string :as string]
             [domina :as domina]
+            [domina.events]
             [domina.css :as dcss]
             [domina.xpath :as xpath])
@@ -465,5 +466,6 @@
           (when (contains? value-map ky)
             (let [val (if val val "")]
-              ((set-form-input val) el))))))))
+              ((set-form-input val) el)
+              (domina.events/dispatch! el :change {}))))))))


Using the above I can now manuelly trigger the jQuery change event using:

(def jquery (js* "$"))

(ef/at ["input[name=zip]"]
       (ev/listen :change #(.change (jquery (.-currentTarget %)))))

--
Cheers
Jacob


On Friday, 28 February 2014 17:39:13 UTC+1, ckirkendall wrote:

[ckirkendall]

Jacob,

Its not really the overhead so much as unintended consequences.  By triggering that event automatically we are simulating a user event.  This isn't in itself a problem but it goes against the basic premise of how these events are triggered.   Most js libraries error on the side of don't trigger user events from code automatically.  In other words if code wants to trigger an event they need to call dispatch.  You will see this even with basic operations like submitting a form.  Calling the submit function doesn't trigger the submit event.  There are also many times where you don't want the event triggered automatically (two way bindings).   

CK

[Jacob Emcken]

Hi

Makes sense. I actually wanted to use the two way binding.

I'll try attach my own watch on the atom to track changes to the :zip key and fire the jquery change event from there.

--
Cheers
Jacob

[Jacob Emcken]

Hi again.

By attaching my own atom watcher on the form data I can get can now fire the jquery change event.
The problem is that the change event fires before the view binding has actually updated the DOM which means that the wrong (old) value is used.

I have tried to insert my own atom watcher both before and after the call to enfocus.bind/bind-form, but no matter what the jQuery change event is triggered before the view binding has updated the DOM.

Ideally (for me *hehe*) I should be able to "listen" for when the view binding had finished its work on the DOM. So I could trigger the jQuery change event here.
Am I missing anything here which Enfocus has already implemented that I can use?
Or if you have any alternative suggestions they would be much appreciated :)

--
Cheers
Jacob



On Monday, 3 March 2014 20:42:04 UTC+1, ckirkendall wrote:

[Creighton Kirkendall]

Hmmm, I think an optional call back function might be the solution to this.  We would need to fire it anytime the view-binding function completed updated.   

--