is a good start)
As for organization, I understand the issue you're running in to. You probably have some components which you dynamically load into pages via PHP and don't know what to do about the fact that the JS would be ideally moved away form the markup in question, but a page may or may not have the need for that JS depending on whether the component loaded in the first place.
When I make a such component, I try hard to be very semantic in my markup, and make good use of the id and class attributes to denote certain markup blocks which have need for behavior binding. I then move all my scripts to the bottom of the page, starting with 3rd party support code such as jQuery.
After having loaded 3rd party support, I load in my own support libraries and APIs. This is code which does not actually do anything during load other than define the classes, functions, etc that I'll need.
Then I have my all my application code and UI bootstrapping code in external scripts and load those as well. The UI binding code is often a single file containing a series of checks for certain structures/classes/IDs in the DOM. If the code detects something it should run against, it does. jQuery is pretty good at helping with this part since you don't have to actually make a check as to whether something existed before running jQuery logic. For example
In this case, if an element with id of "foo" does not exist in my document, the myPlugin method doesn't ever really do anything. So you can have your UI binding file look for as many things in the DOM as needed, running things when appropriate, without a lot of messy checks. The only precaution to this approach is that you should use efficient selectors and query caching to avoid long execution time of the UI binding file.--
d'Vinci Interactive | My Development Sandbox | LinkedIn Profile