We have discussed component initialization on-dom-ready. We can use JavaScriptService which is similar to <h:outputScript target="body" /> - it renders the script on the end of the body - and it renders it just once. This approach follows Yahoo's web app performance recommendations.

We could initialize all components in one pass through the DOM:

$.each(".bs-event", function() {
....
});

#Idea 3 - component destruction

-------------------------------------------

destruction would be done similarly to initialization

RichFaces provides hook in form of cleanComponent, which does both, cleanData and then custom destroy method.

We could improve it and write own destruction for specific elements (similar to construction ^).

#Idea 4 - component re-initialization after AJAX

--------------------------------------------------------------

This would require new hook in oncomplete event, where all the updated sub-tree will be re-initialized.

This is a great start to the discussion - it's unfortunate that the forum software isn't going to be well suited to replying to this multi-topic thread. Perhaps we should start an jira issue for each sub-topic, and carry on the discussion there?

Not a comment on the JSF event bridge, but rather on the jQuery architecture approach as a whole:

I spent the afternoon reading about the jQuery UI widget factory. It provides a "standard approach" for building stateful jQuery plugins, and removes a lot of the boiler-plate javascript for creating/destroying/updating of widgets. Also it provides a nice mechanism for dealing with events / handlers + observers (something which we will do a lot of). The bootstrap js approach is rather an open-slate in this regard (although I do like their data-* approach for plugin configuration).

OTOH I'm sold on twitter Bootstrap / LESS for style and themes.

One constraint I'm wrestling with is the idea that we have to commit our new widgets back upstream. If we create new widgets using Bootstrap styles/CSS names, but write the plugins using the widget factory approach, then we will have no project willing to accept our components upstream.

OTOH, I don't know how realistic it is that our new widgets will actually be accepted upstream, at least not in a timely manner. For a "big" project like jQuery UI or twitter Bootstrap to accept our widget, it would have to be an incredibly popular widget, used by a lot of people. That kind of thing takes time. So we can expect to be maintaining these widgets for a long time ourselves.

So perhaps it is viable to develop jQuery plugins with the jQuery UI widget factory targetting the Bootstrap CSS.