>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]

Reply via email to