For awhile I've been annoyed that we pre-load all bridges mapped in the plugin file (...xap/taghandling/plugin.xml) regardless of how many we're using. Now, the bridge class objects aren't so large, but it adds to the initial request load....
I've written a fix for this---it's fairly simple, just doesn't do a require() when we read the tag mapping in PluginRegistryImpl, but does one in PluginDocumentHandler when we actually need the bridge. It works simply and well. However, this means that some code that works today might not if it needs a bridge class (say, for a constant or a static method) but has no explicit require() for it---up until now, it would have got by because all the bridge classes will have been pre-loaded. I don't think this is a major problem, but it could arise. (On the plus side, if all the strictly needed require() statements are in the class source, dependencies are clearer.) So: are there any objections to my making the loading change? I'll give it a couple of days. (I'm not doing the equivalent for lifecycle objects---the Mco, Datasource, Binding, and Iterator containers---because this code is less well established, and in any event there are only four of them, and the list is not likely to grow much.)
