This file contains a random assortment of notes that might be helpful to someone hacking on wspjs and related modules. STYLE GUIDE (minimalist) • Write code that works • All bug fixes should be accompanied by comments* and tests • Be reasonably paranoid and try to keep extensibility in mind • Don’t ‘fix’ code that already works * Try to not split any infinitives or use a preposition like it’s a conjunction. THE RANDOM NOTES When the JavaScript plugin is loaded, it installs itself as a script handler as well. (The same object serves both purposes.) The same plugin object is shared by frames and any new windows derived from the WWW::Scripter object. When you call $w->get(...), WWW::Scripter fetches and parses the HTML. During parsing, it runs any scripts it comes across (via the script handler’s eval method) and creates event handlers (via the event2sub method). Whenever the JS plugin needs access to the back end (e.g., when run- ning code), it retrieves it via its own back_end method, which, if it does not already exist, creates a new JavaScript environment cor- responding to the current page (response object) of the window (WWW::Scripter object) passed to it. The JE back end (wspjsje) is itself a subclass of JE, so it is the global object. It knows to which window it belongs (with a weak refer- ence), and delegates to it. Whenever a window object is passed to it, if it is its own window, it substitutes itself in its place. Other- wise it creates a wrapper, or proxy object, for that window. The proxy uses AUTOLOAD to delegate to the wspjsje object, which is retrieved via the plugin’s back_end method, and hence is created on demand.