Fix for PR #35 - Triggers success event on parent of replaced element

[txbm]

There were a few solutions to this issue. I felt the most idiomatic one was to simply trigger the event on the parent of the replaced element rather than a document wide trigger.

The problem here is that normal event bubbling won't work because the replaced element destroys the initial event trigger. In order to make it work, you would either have to have a dedicated element specified as an "event proxy" of sorts, or trigger the event document-wide.

Since the document-wide approach felt a bit overboard, and the dedicated element seemed like clutter, I opted to use the parent element since in most of my use cases that element remains untouched and is readily available for subscription by the consuming code.

I also added some semi-colons :)

[paltman]

@petermelias I just did a major update to the code putting the event trigger at the top of the stack rather than the end, I think this might solve the problem. It also means it's much easier to extend and customize the processing side of this plugin.

Would love to know what you think.

Thanks, Patrick

[txbm]

@paltman Without having tested the new release, just browsing the major commit, my initial thought is that there is no explicit reference to the newly added DOM element(s) being passed along with any of the triggers. What I liked about the original trigger for 'bootstrap-success' was that you could pass in the newly replaced / refreshed DOM element so that the handling code could be written without selectors-- otherwise, it requires the handling code to have knowledge of specific selectors, making it more difficult to write abstract custom handlers.

Either way, it's a detail. In terms of the original problem of the event not firing it looks as though you've clearly solved that. I think if I was going to go further, I might trigger secondary events within certain Handler.prototype functions like replace and refresh that go something like 'bootstrap-refreshed' or 'bootstrap-replaced' and each of those triggers would then pass the new DOM element so that the handling code can manipulate it directly without selection.

My primary use case here is rebinding event handlers for elements that have just been replaced. For example, you have a dynamic panel containing some buttons that are also asynchronous. You then need to rebind the click handlers for those buttons as soon as the pane is refreshed by the first handler. It would be smooth to do that inside of a handler that is triggered by an explicit trigger for each type of operation.

This is just my opinion btw, do whatever you feel is best for your library. I am using a fairly modified version of it anyway that I didn't submit as a PR because I wasn't sure what your development road-map looked like.

Peter

[paltman]

@petermelias these are EXCELLENT suggestions? Would you mind creating an issue with this information and I'll work on getting it implemented? I'll be happy to create it but thought you might want to be the creator so you get proper notification and all.

[paltman]

Also, i might need some help understanding what you mean by prototype event

[txbm]

@paltman I'll implement it, let me just re-fork your newly renamed repo. Not sure where you saw "prototype event".

Anyway, I'll try and review the library in more detail and start actively contributing since I'm using this production.

[paltman]

@petermelias awesome!!

[paltman]

@petermelias I have added #46 to the 1.0 milestone. I think this idea you propose, fully test coverage, and more complete documentation are all that are needed to release 1.0. I'll focus on documentation and test coverage while you address #46.

If you don't think you'll get to it, please let me know and I'll take a crack at in a couple of weeks. Thanks again for all your help.

[paltman]

@petermelias just wanted to check in to see if you have had an opportunity to work on this feature. i'd love to see what you were describing.

[txbm]

@paltman Hey man, things got real busy. Won't have time to do a lot of open source stuff until later in September. Sorry if that doesn't fit your timeline but if you're still working come that time I'll pitch in where I can.

[paltman]

@petermelias no problem, I completely understand.