Thoughts on Events

alfonsoml wrote:In the Data object I would always add a reference to the FCKeditor instance related to the event. It might be possible to get it from the sender object, but it might involve more manipulations, and so having it there will be a handy shortcut (of course in many/most of the situations sender == editor instance)

Good point. I forgot about this important feature, which is btw the only parameter we have in today's implementation.

I've updated the docs, adding it as the "editor" property in the Event object. The data properly should be reserved to the event publisher to pass any kind of data.

alfonsoml wrote:A point to evaluate is a queue for events. As explained in a bug, if some change is done while in an event handler, several onselectionchange events are fired, but it's mostly a waste of CPU, the end result would be the same if those events fired in the middle are queued (and unified as a single one) and fired after there is nothing else to do.
Of course this could be done only with events that aren't cancelable, and that it's really possible to merge without affecting the process.

This makes sense, specially for an event like selectionchange. But, it the other hand, this delayed/grouped call can't be a rule. It is quite easy to come with other events examples that would break in such case. For example, a counter that must be increased every time an event happens (no grouping) or an event that causes changes that are relevant to other listeners in the original even queue (no delay).

It sounds like this specific issue can't be solved by the event system itself, but something to be handled by the publisher. The selectionchange event is quite critical and deserves special attention to find solutions to enhance its performance. We'll keep that in mind, but maybe there is not need to generalize this issue to all other events.

But, we could propose a feature to the event system. We could extend the "fire" method by adding a parameter named "grouped", which means that listeners should be called only when all other events have been processed and just a single call should be made. It would help us optimizing the selectionchange event.

Does that makes sense?