To separate code into bundles, create a directory called
modules within your application (or
framework). For example, a directory structure for an app with two modules and a framework with one module would be,
my_project/ apps/ my_app/ modules/ settings_pane/ ... all code in the settings_pane bundle sign_up_pane/ ... all code in the sign_up_pane bundle frameworks/ my_framework/ modules/ framework_config/ ... all code in the framework_config bundle
Once you've got your modules defined, you need to decide how they should be made available to your application. There are three different loading styles that we can use for modules, 'inlined_modules', 'prefetched_modules', or 'deferred_modules', each with its own strengths and weaknesses.
This is specified in the Buildfile for your application or project. For example,
config :my_app, :inlined_modules => [:sign_up_pane], :prefetched_modules => [:settings_pane], :deferred_modules => [:'my_framework/framework_config']
Inlined modules include the module as an unparsed String within the main application code. This means inlined modules are guaranteed to be available within a loaded application, making them the best option for supporting offline mode. They, however, add to the initial load time of the main application code and take up space (less than when parsed) in memory.
Prefetched modules store the module as an unparsed String in a separate file from the main application code that is lazily loaded. This means that prefetched modules are not guaranteed to be available within a freshly loaded application. Instead, SproutCore will lazily fetch these modules individually when it detects that the application is idle, which means that the initial load time of the main application is improved, but importing a prefetched module may take slightly longer if it hasn't yet been fetched and going offline before a prefetched module is loaded will cause the module load to fail. Therefore, this loading style is most suitable for online-only applications that want to optimize their loading speed, but don't want noticeable delays when modules are first accessed.
To recap, the different loading styles and their benefits and costs are,
- Pros: offline ready, improved launch time, improved memory management, always load quickly
- Cons: still delays initial load time, still consumes memory
- Pros: best possible launch time, improved memory management, almost always load quickly
- Cons: must be online (at least for a little while), still consumes memory
- Pros: best possible launch time, best possible memory management
- Cons: must be online, loads slowly
Defined in: module.js
Instance Method Detail
YES if the module is ready; NO if it is not loaded or its
dependencies have not yet loaded.
Asynchronously loads a module if it is not already loaded. If you pass a function, or a target and action, it will be called once the module has finished loading.
If the module you request has dependencies (as specified in the Buildfile) that are not yet loaded, it will load them first before executing the requested module.
- YES if already loaded, NO otherwise
Call this in order to resume normal behavior of the methods here, and to finally perform any calls that may have occurred during suspension. Calls will run in the order they were received.