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 on www.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]
