FLUID-4878: Cannot use jquery functions directly as IoC Functions or listeners to events

Description

Because of jQuery's use of "this" the framework is not able to handle jQuery functions that are passed into the func property of an IoC call or the listerner property for an event.

Example:

listeners: {
onCreate: {
listener: "{that}.dom.reset.click",
args: ["{that}.reset"] // a function
}
}

Comments

• Justin Obara commented 2013-01-07T11:13:29.083-0500

  Perhaps we could create a new property to pass in jQuery functions similar to the refactored jqunit.

• Antranig Basman commented 2013-04-13T03:31:34.477-0400

  Transcript of private chat with jobara:

  (14:16:42) Justin Obara: when do you think we might see the jQuery thing i mentioned in the channel resolved?
  (14:17:01) Justin Obara: i'm working on something now, but will resort to just writing a wrapper function around it
  (14:17:02) AntranigBasman: I am just thinking about it now : P
  (14:17:15) AntranigBasman: It's actually quite a tricky problem
  (14:17:24) Justin Obara: because it isn't thatist?
  (14:17:48) AntranigBasman: Yes, well.... the idiom of the entire framework is based around "functions as first-class values"
  (14:18:06) AntranigBasman: And the problem is, typically, once you have resolved an EL expression, that's that
  (14:18:34) AntranigBasman: All we have at the end of the process of resolving "{that}.dom.reset.click" is the raw function
  (14:19:00) AntranigBasman: And there's just too much machinery to get through to somehow instruct the system that IN ADDITION to that value, you also want the value of "{that}.dom.reset"
  (14:19:20) AntranigBasman: But I think I have the beginnings of an idea how to fix it
  (14:19:58) Justin Obara: yes.. i can see how that would be an issue.. awesome that you have something started thoug…
  (14:20:23) Justin Obara: in the meantime i guess i'll just make the small wrapper around the jquery call…
  (14:20:34) AntranigBasman: Yes
  (14:20:38) AntranigBasman: It might take a little while
  (14:20:53) Justin Obara: any best practices around that.. write now the code looks like this
  (14:20:54) Justin Obara: fluid.uiOptions.fatPanel.bindReset = function (elm, resetFn) {
  $(elm).click(resetFn);
  };
  (14:21:02) Justin Obara: which is small, but feels somewhat offputting to me
  (14:21:13) Justin Obara: so many typos 😞
  (14:21:39) AntranigBasman: Yes, its undesirable
  (14:21:47) AntranigBasman: You could make a "general binder"
  (14:21:55) AntranigBasman: Which accepts the name of the jQuery event as the 1st property
  (14:22:06) AntranigBasman: SOmething which basically has the syntax of "jQuery.bind"
  (14:22:42) Justin Obara: i was thinking of that.. but should i support the eventData option
  (14:22:42) Justin Obara: http://api.jquery.com/bind/
  (14:22:55) AntranigBasman: Doesn't seem necessary for now
  (14:22:56) Justin Obara: and if so, i'm not sure how to make that take any number of arguments
  (14:22:58) Justin Obara: okay.. cool

• Antranig Basman commented 2013-04-13T03:33:16.081-0400

  And today's discussion:

  [13:44] <Justin_o> Bosmon: https://github.com/jobara/infusion/commit/1303f387a78dbdf6ff146103e71d2229337ed63d
  [13:44] <Bosmon> Thanks
  [13:45] <Bosmon> Justin_o: That seems like a very reasonable implementation, other than the name : P
  [13:46] <Justin_o> Bosmon: i was thinking there might be some issues with the name..do you have a recommendation for something better?
  []
  [13:48] <Bosmon> Justin_o - that's a good question.... there's an interesting issue about whether it either does do, or should do, the same as jQuery.bind ....
  [13:49] <Bosmon> As it stands, you could say that it is both more general and more comprehensible than jQuery.bind itself since it "does exactly what it says on the tin"
  []
  [13:52] <Bosmon> Justin_o - what do you think about naming the function as "fluid.bind", putting it in Fluid.js, and removing the first line of its code
  [13:53] <Bosmon> The IoC references system already manages the responsibility of ensuring that the first argument would be a jQuery
  [13:53] <Bosmon> And the behaviour of this code is really more general - it will bind on to "any this-ist function"

• Antranig Basman commented 2013-04-23T02:49:56.185-0400

  More discussion from last week:

  [13:07] <Bosmon> I was thinking of starting to implement our dedicated framework functionality for FLUID-4878
  [13:07] <Bosmon> What do you think of the following syntax: http://pastie.org/7665641
  [pastie holds this:
  invokers: {
  bindReset: {
  "this": "{fatPanel}.dom.reset",
  "method": "click"
  "args": "{arguments}.0"
  }
  },
  ]
  [13:07] <Bosmon> Also cindyli
  [13:09] <Justin_o> Bosmon: looking at it now
  [13:09] <cindyli> Bosmon: what is "this"? always a dom object, could it be other stuff?
  [13:10] <Bosmon> It can be any "this"
  [13:11] <Justin_o> Bosmon: would it be possible and would it make sense, to have "method" be "funcName" so that it looked more like regular invokers?
  [13:12] <Bosmon> Justin_o - I think it would undesirable
  [13:12] <Bosmon> Since the expected values are completely different
  [13:12] <Bosmon> "method" must always be a single string representing a direct method on the object
  [13:12] <Justin_o> Bosmon: ah i see now
  [13:12] <Bosmon> Whereas "funcName" can be a general EL path representing a method's global name
  [13:13] <Bosmon> So for example I have this in my current Uploader branch, which doesn't work:
  [13:13] <Bosmon> enableBrowseButton: {
  [13:13] <Bosmon> func: "{that}.swfUpload.setButtonDisabled",
  [13:13] <Bosmon> args: false
  [13:13] <Bosmon> },
  [13:13] <Bosmon> As it turns out, swfUpload also expects to be a "this"
  [13:13] <Bosmon> And we would rewrite this as follows:
  [13:14] <Bosmon> Anyway, I meant to write this:
  [13:14] <Bosmon> enableBrowseButton: {
  [13:14] <Bosmon> "this": "{that}.swfUpload"
  [13:14] <Bosmon> method: "setButtonDisabled",
  [13:14] <Bosmon> args: false
  [13:14] <Bosmon> },
  [13:15] <Justin_o> Bosmon: just to double check, does "this" always refer to the parent of the method?
  [13:15] <Bosmon> Justin_o - yes
  [13:16] <Bosmon> It's no different to the arguments for your "fluid.bind", only differently packaged
  [13:19] <Justin_o> Bosmon: cool 🙂
  [13:19] <Justin_o> Bosmon: could we do something like this http://pastie.org/7665848
  [13:20] <Bosmon> Justin_o - isn't that just the first example in my pastie?
  [13:22] <Justin_o> Bosmon: hmm maybe i'm missing something .. i was suggesting to remove the "this" property and source it instead from the elpath to the method that you'd want to call
  [13:22] <Bosmon> Oh, right
  [13:22] <Bosmon> yes, that would be more difficult to implement
  [13:23] <Bosmon> Don't you think it might also be more unclear?
  [13:23] <Justin_o> Bosmon: maybe 🙂 just exploring ideas… i guess it is nice that the "this" is explicity
  [13:23] <Justin_o> "explicit"
  ...
  [13:27] <Justin_o> Bosmon: i think that's probably all i'd have to really comment… your first suggestion is pretty clear and explicit and i think the syntax would be usable. And of course, I'd love to have this type of declarative way of calling things in the framework 🙂

• Antranig Basman commented 2013-05-02T17:24:11.960-0400

  Merged in to trunk at revision d0f009b