I know I have read up on this before, but I can't come up with the right search terms to find the articles now. Is there a well thought out and tested pattern that handles initialization in sitiation like this?

Thanks.

EDIT: Upon re-reading this, I think a little context will inform answers.

In my case, each module / submodule is in its own file. The base module defines the basic functionality of the site, and sub-modules enable different features. For example, a sub-module may wire up auto-completion on a search box, and another may turn a static header image into a rotating banner. Sub-modules are enabled/disabled by the CMS, so I really do want to divorce explicit calls inside the base module so everything can be managed by the CMS. I also that there are CMS specific ways to accomplish this, but I looking for a generic Javascript pattern for doing this to provide consistency and resuablity between projects that may use a different CMS.

Depends whether I need to supply a public API to other users, which backbone does a lot better. I prefer to make modules driven by an init function for initial configuration and for the rest completely event driven.

[Edit]

Given the edited question I have a different pattern for this. Each file defines a function on some object in my case it was $.FooBar.plugins

I am working on a delegate pub/sub pattern that may work for the problem you seem to describe here. I think the goal is to not end up repeating code in our sub-objects that we've already written in our parent objects, unless that code is completely specific to that module.

In general, I think we should get away from this idea that we must replicate the "classical inheritance" style of programming that exists in other languages, and simply leverage the capabilities that JavaScript natively has. "Inheritance" can be more about invoking properties and methods in an execution context (similar to how we use .call() or .apply()), and doesn't need to beget a massive codebase full of modules "extending" other modules, only to end up treating them like completely isolated and individual objects anyway.

I'm going to soon put this to use in a bigger project and see how it works out when dealing with a lot more code (warning: YES, I set properties on objects' __proto__):

The idea here is that you write one API (or module if you like) for one type of object. For example, your module may be a "View API" which contains all of the methods a view object may ever care about. You write those methods once, and never again. By writing the code within those methods as if the module were any future invoking object (using this or a once-defined stand-in for this), you can avoid rewriting or overriding properties and methods later down the line. So, this API effectively becomes the central delegate (or you could call it an abstract class if you want) for any future concrete objects that may be interested in its functionality (e.g. views). We already write centralized APIs on the server that act as delegates for data (most web APIs); why should we not extend this same philosophy to the client side to better organize our views, client-side models, and other objects?

The primary difference between this delegate pattern and traditional module patterns, is that with this pattern you'll typically end up with one, somewhat lengthy module that looks and feels like an API with methods that can produce very different results depending on the invoking object (and thus the execution context), instead of having many semi-lengthy modules that have a mix of logic, methods, and unique properties which ultimately cause them to repeat each others' code. With this pattern, you'll probably see a lot less conditional logic, and you'll never have to use var self = this again -- this is what makes it an abstract delegate instead of a concrete module. Frameworks like Backbone nearly accomplish this, but they ultimately don't. Backbone is a framework for "object inheritance" and modular organization of code -- and that's great -- but I think biggest value it adds is actually the fact that it's gotten people to agree on "some standard" (but I could say the same about CoffeeScript; eww...).

The final aspect of this pattern touches on your first example. By including basic accessor methods and pub/sub functionality in the core, we can truly create objects that are completely in sync with their parents when we want them to be, and have the ability to sever their relationships whimsically, as needed -- if needed. I've used prototypes to accomplish this, but you could probably think of another way too (using constructors). I think it results in a truer version of pub/sub where publishers know nothing about their subscribers, and subscribers only know about publishers when and if they subscribe to them.

For more on this, I have a more detailed, documented example, which outlines a few of the possible use cases in a gist I created. Of course, the names of the variables should probably change to names that make more sense in your project -- I used these names to convey what their purpose is. Here's the gist: https://gist.github.com/bennyschmidt/5069513

I am interested to hear more about other modular design patterns you all have thought of. :>