Prototype

Comments and changes to this ticket

• 

  John-David Dalton May 13th, 2008 @ 08:51 AM

  Can you compare your patch to Juriy's version and take the good parts and combine them?

  I think he has ya beat on code size footprint.

  It's definitely worth a look :)

  http://github.com/kangax/protoli...

  -- JDD

• 

  John-David Dalton May 13th, 2008 @ 08:53 AM

  • → Title changed from “[Patch] Event.fire emits normal HTML events” to “Event fire normal html events.”
  • → Milestone changed from “” to “1.6.1”
  • → Assigned user changed from “” to “Juriy Zaytsev”
• 

  Viktor Kojouharov May 13th, 2008 @ 09:17 AM

  @John,

  Someone else will have to do that. I'm biased, so I probably won't make the correct decisions regarding what parts from what to take.

  <

  He definitely beats me in terms of code-size.

  Certain things that I personally didn't like:

  On the bad side, 'simulate' lacks key event simulation.

  Adding another method which is essentially 'fire', but with regular HTML events is a bit redundant.

  I don't know whether the regex match will present any slowdown, as opposed to a hash fetch.

  The default options, in terms of bubble and cancel will be wrong on some of the events. That's the reason I went with a separate bubble|cancel default option for the HTML events.

  MY_BIASED_OPINION

  to Juriy, please don't take the above heredoc the wrong way. I'm sure you'll have planty of objections against my patch as well :)

• 

  Viktor Kojouharov May 13th, 2008 @ 09:18 AM

  That lone '<' in the previous comment was the start of the heredoc 'MY_BIASED_OPINION'.

• 

  Tobie Langel May 13th, 2008 @ 10:18 AM

  • → State changed from “new” to “enhancement”
• 

  Juriy Zaytsev May 13th, 2008 @ 12:36 PM

  • → State changed from “enhancement” to “new”

  Viktor,

  the snippet from protolicious repository was not actually intended to be used as a patch : ) , but rather a standalone replacement of Event.simulate from unittest.js (which currently supports FF only)

  The reason for not including KeyEvents is a lack of research on this matter. YUI, for example, does not support them and I have a feeling that it's due to a large amount of quirks in the way browsers handle them.

  Having said that, I would really like to hear why such support would be useful. I can't really think of any use cases other than UI testing - exactly the reason why I left it in unittest.js (http://thinkweb2.com/projects/pr...)

• 

  Viktor Kojouharov May 13th, 2008 @ 04:16 PM

  Juriy,

  As far as usefulness is concerned, there are a few things to point out. First, it makes the fire implementation more complete (as long as it's working, and so far it is). Second, it's about as useful as any other event. You want to notify some potential listeners that you did something. Sometimes you want to cheat, and notify them, even if you didn't do exactly that 'something'. And sometimes, we want to fire them, just because the browser pissed us off, and didn't fire them on its own ('change') :). But I'm mostly aiming for complete, it would just suck to be able to fire a mousedown, but not a keydown.

• 

  Juriy Zaytsev May 15th, 2008 @ 11:28 PM

  Viktor,

  "Completeness" aside, I'm still in doubt about adding a full-blown event simulation just to support rare use cases. I would still vote for adding it to unittest.js, though.

• 

  John-David Dalton May 16th, 2008 @ 09:11 AM

  • → State changed from “new” to “enhancement”
• 

  Steven Pothoven May 19th, 2008 @ 02:02 PM

  I just want to voice that I was just about to submit a similar ticket myself and would thus be in favor of seeing this addition. I've had to use this functionality in several situations where an Ajax response updates a field value, but the corresponding change event does not get triggered and thus other fields which depend on the first field are not correctly updated.