I go with 3). That's what I meant with the iterating over all your modules in my last post. I've created a jsfiddle to give you an example: http://jsfiddle.net/NWNwL/8/
I identify my modules using the css-Klasses from https://github.com/stubbornella/oocss/wiki/Module. All my modules have this structure so it's easy to find them. In my example can see that I iterate over all .mod and the get the actual name of the module (.modModulename) and use it to execute it's specific code. As I mention in the comments, you can load an external js file dynamically at this point. Make sure you pass the $contex (or node), so you can work with the actual module instance. As I mentioned in my last post, Terrific on terrifically.org does exactly this and more. Check out this jsfiddle as well: http://jsfiddle.net/brunschgi/uzjSM/. Each module has a few events (hooks) called beforeBinding, onBinding and afterBinding. You can also load dependencies. The Terrific bootstrap registers the page as module, registers all other modules and the starts (initializes) everything. No timing worries, dependency worries. Everything is handled. - TJ On Aug 5, 2011, at 1:39 AM, dtang85 wrote: > From your external JS file, how do you know what modules will be on a > given page? The possible ways I can think of are: > > 1) to use some identifier from the URI to determine which modules to > load (for example, if your site was http://mysite.com/about, use the > 'about' segment to identify which modules are on the about page) > 2) to use an inline script block on each page and select which modules > u would like to activate for that page. > 3) check for certain elements on the page and load modules that use > those elements. (for example, if there is a div with an ID of 'news' > on the page, you load the news module) > > > On Aug 3, 11:46 pm, Thomas Junghans <[email protected]> wrote: >> Hi, why not iterate over all modules on your page and only execute those? >> You will need to use a naming convention such as .mod from oocss so your >> modules can be identified. >> There's a framwork which does this called Terrific onwww.terrifically.org. >> Or search for terrific+sandbox+addmodules. >> >> Cheers >> Tj >> >> Sent from my iPhone >> >> On 04.08.2011, at 05:56, dtang85 <[email protected]> wrote: >> >>> In the Core-Sandbox-Module pattern, Nicholas has methods on the Core >>> object to start and stop modules. Some pages in your site may only >>> contain certain modules. Would you place, for example, >>> Core.start('module 1') in an inline script block on the pages that use >>> that module, so that each page only starts the required modules, or do >>> you start all the modules in the external script file and if the page >>> doesnt have the module, it'll only waste a little bit of effort? >> >>> On Jul 19, 7:19 pm, 张晋 <[email protected]> wrote: >>>> Could you give me some basic demo?Thanks very much! >> >>>> 2011/7/19 Sam Foster <[email protected]> >> >>>>> A simple, useful rule of thumb when considering architecture, is to >>>>> never have a object communicate directly with something it didn't >>>>> itself create. I.e. calling methods on objects that are assumed to >>>>> have been created also - bad thing. That's how I break down when to >>>>> call methods directly vs. when to use pub/sub. The thing that created >>>>> me should hand me a list of pub/sub channel names, or a prefix which I >>>>> can use to push out and listen for events. If 2 things need to be >>>>> connected, the connection is shaped by the thing that makes them. >> >>>>> Following this simple rule reveals a lot of of hidden assumptions >>>>> which can later turn into bugs, and it makes for more testable code. >>>>> It also makes clear when you need some kind of a manager or controller >>>>> to sit above components and dispatch events, and hold the shared state >>>>> for the collection of objects it manages. >> >>>>> /Sam >> >>>>> -- >>>>> To view archived discussions from the original JSMentors Mailman list: >>>>> http://www.mail-archive.com/[email protected]/ >> >>>>> To search via a non-Google archive, visit here: >>>>> http://www.mail-archive.com/[email protected]/ >> >>>>> To unsubscribe from this group, send email to >>>>> [email protected] >> >>> -- >>> To view archived discussions from the original JSMentors Mailman list: >>> http://www.mail-archive.com/[email protected]/ >> >>> To search via a non-Google archive, visit >>> here:http://www.mail-archive.com/[email protected]/ >> >>> To unsubscribe from this group, send email to >>> [email protected] > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected] -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
