Welcome, guest ( Login )

WikiHome » BootstrapBloat

BootstrapBloat

Version 39, changed by owen 12/09/2006.   Show version history

OBSOLETE?

Update 5/16/2006: This work has been completed. For more information on the methods that were removed, and how to use still use them in 0.3+ releases, see UsingCompatibilityPackages.

Refactoring Plans

This is a summary of changes that will be done based on the Bootstrap Documentation section below.

  • Put up a blog post and notify the dojo lists that the following methods will be removed. If someone screams, then the method(s) may be kept around, but not likely. Instead, give instructions on the wiki on how a developer could make their own compatibility package. Removed methods:
    • dj_throw(), dj_rethrow() (use dojo.raise() instead)
    • dj_debug() (use dojo.debug() instead)
    • dj_unimplemented() (use dojo.unimplemented() instead)
    • dj_deprecated() (use dojo.deprecated())
    • dj_inherits()
    • dojo.hostenv.setBaseScriptUri()
    • dojo.loaded() (Alex/Dylan, can we really remove it?)
    • dojo.hostenv.getLibraryScriptUri() (only keep it in hostenv_jsc.js)
    • dojo.hostenv.require) (use dojo.require() instead)
    • dojo.requireAfter()
    • dojo.requireIf() (use dojo.requireAfterIf() instead)
    • dojo.conditionalRequire()
    • dojo.requireAll()
    • dojo.hostenv.provide() (use dojo.provide() instead)
    • dojo.exists() (change code to use dojo.evalObjPath() if possible)
    • dojo.hostenv.byId(0 (use dojo.byId() instead)
    • dojo.hostenv.byIdArray() (If really useful, merge the functionality into dojo.byId?)
    • dojo.hostenv.conditionalLoadModule() (use dojo.kwCompoundRequire() instead). dojo.hostenv.conditionalLoadModule() will probably be kept around, but you are strongly encouraged to change to dojo.kwCompoundRequire(). The dojo codebase will be changed over to use dojo.kwCompoundRequire(). Right now dojo.kwCompoundRequire() is an alias to dojo.hostenv.conditionalLoadModule() anyway.
  • Move the PL functions mentioned in boostrap1.js down to bootstrap2.js. Make bootstrap2.js the package loader. Rename to loader.js?
  • Move dojo.experimental into its own package. Packages that are experimental can import that package. It will also give a nice indication at the top of the package that some things are considered experimental.
  • Move dojo.debug, dojo.debugShallow and dojo.profile into a separate package that is only included if djConfig.isDebug is true. Only have empty stub functions in bootstrap1.js for these methods.

Bootstrap Documentation

We need to figure out which of these really need to be at the core. More importantly, we need to discuss which parts of dojo are really necessary. It was said in today's IRC meeting that for a build, we might not even want to include a truly modular system. That might sound extreme, but it is the type of thing that should be discussed.

We should determine what items a user expects to use from the core, which of these functions are actually used in a core situation, and which are downright stupid. The question to ask is "Would I always require this every time I use dojo".

Notes for codes used below:

  • PL - used by package loading
  • Core - something that is used by lots of things, but not package loading.
  • Red color means it is a candidate for deletion.
  • Blue color means it is a candidate to move somewhere else (does not include core or PL functions).
  • If only a few places reference the function/variable, then they will be listed. If there are many references throughout the codebase, then just word "many" will be used.

bootstrap1

  • dj_global variable
    • Core, PL
    • many
  • dj_undef function
    • Core, PL
    • 1 use in Logger.js
    • 13 uses bootstrap1.js: 1 reference in PL function, other refs are Core. May be able to remove PL reference in dojo.hostenv.loadModule.
    • 4 uses in browser_debug.js
    • 1 use in behavior.js. Might be possible to remove this reference.
  • djConfig object (if not set)
    • Core, PL
    • many
  • dojo object (if not set)
    • Core, PL
    • many
  • dojo.version object
    • Used to set dojo.render.ver, but no one references that or dojo.version. Not used by PL or Core, but may be useful for PL multiple dojo versions.
  • dojo.evalProp function
    • Core, PL (via dojo.hostenv.moduleLoaded())
    • Used by dojo.parseObjPath and dojo.evalObjPath
    • Used by lang/extras.js::dojo.lang.getObjPathValue
  • dojo.parseObjPath function
    • Core
    • Used by lang/extras.js::dojo.lang.getObjPathValue and dojo.lang.setObjPathValue
  • dojo.evalObjPath function
    • Core, PL (via dojo.hostenv.moduleLoaded())
    • many
  • dojo.errorToString function
    • Core, PL (via dojo.raise())
    • 2 refs in bootstrap.js: dojo.raise() and dojo.debug()
  • dojo.raise function
    • Core, PL
    • many
  • dj_throw function (also called dj_rethrow) DEPRECATED
    • dj_throw: multiple references in the hostenv_*.js files, but not in hostenv_browser.js Replace with dojo.raise().
    • No refs to dj_rethrow
  • dojo.debug function
    • Many references, but move to browser_debug.js, and just put a stub function in bootstrap1.js? Rename browser_debug.js to debug.js?
  • dj_debug DEPRECATED replace with dojo.debug
    • 1 ref in widget/html/ContextMenu.js
    • 1 ref in widget/Parse.js
  • dojo.debugShallow function
    • Some references, but move to browser_debug.js or new debug.js?
  • dj_eval function
    • PL (dojo.hostenv.loadUri() and browser_debug.js stuff for writeIncludes()).
    • Core, but most references are in browser_debug.js and some hostenv_*.js files.
    • It would be nice to get rid of it, but according to function comment it is needed for JSC and Mozilla/Spidermonkey compatibility.
  • dj_unimplemented function
    • Core
    • Replace with calls to dojo.unimplemented. Remove it (not any code savings, just clearer API).
  • dojo.unimplemented function
    • Core, PL (but only as the body for some stub functions in bootstrap1.js)
    • many
  • dj_deprecated function
    • Core
    • Replace with calls to dojo.deprecated. Remove it (not any code savings, just clearer API).
  • dojo.deprecated function
    • Core
    • many
  • dojo.experimental function
    • Only one reference: data/__package__.js Would a simple dojo.debug() message do for now? Is the larger issue how to mark APIs as stable or not (even down to a function level)?
    • Brian: Yes, I added dojo.experimental after some IRC discussion, as an attempt at warning users about new APIs that are unstable (at a function/file/packages granuarily). We could replace dojo.expimental calls with simple dojo.debug() messages, or we could move the experimental() funtion out of bootstrap1.js to somewhere more appropriate (like maybe a dojo.experimental?). I don't think it matters how exactly we flag APIs as unstable, but I think it would be useful to start getting in the habit of flagging them, and doing it in some consistent way.
  • dj_inherits function DEPRECATED
    • Only one, commented out reference in logging/Logger.js
  • dojo.inherits
    • Core
    • many
  • dojo.render function
    • Core, PL
    • many
  • dojo.hostenv.getBaseScriptUri function
    • Core
    • many
    • Does it need to be part of dojo.hostenv?
  • dojo.hostenv.setBaseScriptUri function
    • No references in code. Have users use djConfig.baseScriptUri directly? There was a note about JScript .NET, but if it is somehow relevant, can it just use djConfig.baseScriptUri? May be important in the multiversion support, but remove it until a need is found.
  • dojo.hostenv.loadPath function
    • PL. Used almost exclusively dojo.hostenv.loadModule()(multiple times), and 3 times in hostenv_adobesvg.js version of loadModule().
  • dojo.hostenv.loadUri function
    • PL
    • Used by dojo.hostenv.loadPath() and loadUriAndCheck().
    • Overridden in browser_debug.js
    • 2 definitions in hostenv_adobesvg.js?
    • Other definitions in hostenv_*.js
  • dojo.hostenv.loadUriAndCheck function
    • PL
    • Used only in bootstrap1.js::dojo.hostenv.loadPath().
    • Set to empty function in hostenv_svg.js
  • dojo.loaded function
    • PL
    • Empty function. Not sure why it is there. For AOP event bindings? That would bypass people using dojo.addOnLoad(). Suggest removing?
  • dojo.hostenv.loaded function
    • PL
    • Called by dojo.hostenv.modulesLoaded.
  • dojo.addOnLoad function: Definitely a requirement
    • PL
    • Must keep it.
  • dojo.hostenv.setModulePrefix function
    • PL
    • Change dojo.setModulePrefix() (defined in bootstrap2.js, but just an alias).
    • A little problematic, since hostenv_svg.js als defines this function, but just sets it to an empty function.
  • dojo.hostenv.getModulePrefix function
    • PL
    • 1 reference in dojo.hostenv.loadModule().
    • hostenv_svg.js defines this as an empty function.
  • dojo.hostenv.getName function
    • Core
    • 0 references, but possibly informative?
  • dojo.hostenv.getVersion function
    • Core
    • 0 references, but informative? hostenv_rhino.js and hostenv_spidermonkey.js redefine it.
  • dojo.hostenv.getText function
    • Core, PL
    • many. style.js and widget/domwidget.js use it.
  • dojo.hostenv.getLibraryScriptUri function
    • Core?
    • 0 references. Default says "unimplemented". Defined only in hostenv_jsc.js. Some hostenv_*.js look at dojo.hostenv.library_script_uri_, but not hostenv_browser.js. Can we remove this function?
  • dojo.hostenv.modulesLoaded function
    • PL
    • Used in bootstrap2.js::dj_load_init(), which is registered as a window.onload listener.
    • Also defined in hostenv_adobesvg.js. Called in its version of dojo.hostenv.loadUri().
  • dojo.hostenv.moduleLoaded function
    • PL
    • Called by many (all?) __package__.js files.
    • Could this be moved into dojo.hostenv.startPackage(), and use dojo.provide (which is dojo.hostenv.startPackage) in the __package__.js files?
  • dojo.hostenv._global_omit_module_check variable
    • PL
    • Used only by dojo.hostenv.loadModule, but tweaked in browser_debug.js as part of dojo.hostenv.writeIncludes().
  • dojo.hostenv.loadModule function
    • PL.
    • many. Backs dojo.require.
    • What is the difference between hostenv_adobesvg.js function and the one in boostrap1.js? In hostenv_svg.js, there is a comment about killing it.
    • Can we just rename to dojo.require? If we take care of the svg files mentioned above, it seems possible to rename it.
  • dojo.hostenv.startPackage function
    • PL
    • many. dojo.provide() is really just function. Can we just use dojo.provide()? startPackage() is called directly in hostenv_adobesvg.js, hostenv_browser.js and hostenv_svg.js to start the "dojo.hostenv" package. Wouldn't that have already been done by bootstrap1.js? What about the other hostenv_*.js files that don't use it? Try to get to just dojo.provide().
  • dojo.hostenv.findModule function
    • PL
    • Used by dojo.hostenv.loadModule() and in hostenv_adobesvg.js::dojo.hostenv.loadModule().

bootstrap2

  • dojo.hostenv.conditionalLoadModule function
    • PL
    • many (all?) __package__.js files. dojo.kwCompoundRequire() is an alias for this function. Change name to kwCompoundRequire() since it matches better with require/provide syntax.
  • dojo.hostenv.require UNUSED
    • PL. Alias for dojo.hostenv.loadModule.
    • 0 references in code.
  • dojo.require function
    • PL. Alias for dojo.hostenv.loadModule. Change loadModule's name to dojo.require (see loadModule comments).
  • dojo.requireAfter UNUSED
    • PL. Alias for dojo.require
    • Only one reference, in browser_debug.js, but it can be removed (in a regexp).
  • dojo.requireIf function
    • PL.
    • 0 direct references. Move function body to requireAfterIf, which is referenced.
  • dojo.requireAfterIf
    • PL
    • many (in widgets). Move requireIf's function body to here.
  • dojo.conditionalRequire
    • PL
    • 0 references
  • dojo.requireAll function
    • PL
    • 0 references in dojo source. Can we remove it?
  • dojo.kwCompoundRequire function
    • PL
    • 2 references in __package__.js files. Change references to conditionalLoadModule() to this name instead, and move function body to this method name.
  • dojo.hostenv.startPackage
    • PL
    • A few direct references in hostenv_*.js files.
    • Standardize on dojo.provide instead of this function name.
    • hostenv_svg.js has an alternate definition, but still switch to dojo.provide.
  • dojo.hostenv.provide
    • PL
    • No direct references. Remove in favor of dojo.provide.
  • dojo.provide function
    • PL
    • many
  • dojo.setModulePrefix function
    • PL
    • Alias for dojo.hostenv.setModulePrefix. Can we just switch to this version instead? Unfortunately, dojo documentation mentions both
    • 0 internal references, but used heavily by applications.
  • dojo.profile object
    • Core
    • many. Perhaps move to a debug.js file instead?
  • dojo.exists function
    • Core
    • 3 refs in html.js, 2 in widget/treenode.js
    • Compare with dojo.evalObjPath. Can dojo.evalObjPath be used instead? If so, can dojo.exists be removed?

hostenv_browser

  • anonymous function
    • 1st part parses the query string to look for djConfig parameters. Is this used by anyone?
    • 2nd part parses script src to find baseScriptUri/baseRelativePath (if not already in djConfig). This sort of code is also in dojo.js. Since dojo.js runs first, remove this block of code, or merge any important differences with dojo.js.
    • 3rd part does browser detection and sets variables off of dojo.render. There is one block that is concerned with detecting Adobe SVG. Can it be removed?
    • Has a dojo.hostenv.startPackage("dojo.hostenv"); line. Isn't this package created already in bootstrap1.js?
  • dojo.hostenv.getXmlhttpObject function
    • Core, PL
    • 1 ref in dojo.hostenv.getText (defined in this file)
    • 2 refs in io/browserio.js
    • Redefined in hostenv_dashboard.js [Yeah, it allows OS X Dashboard to use curl. Besides, defining a function in two different hostenv files isn't even an issue. -Neil]
  • dojo.hostenv.getText function
    • Overrides definition that was created in bootstrap1.js. See that reference for more info.
  • dojo.hostenv.println function
    • Core
    • Used by dojo.debug() and dojo.raise()
    • Redefined in Firebug.js
    • Redefined in hostenv_*.js files.
  • dj_addNodeEvtHdlr function
    • Only used to register dj_load_init() for the window onload action.
    • Inline this method for the dj_load_init() onload registration to avoid others from using it, and since it may go away at some point if a domcontentloaded approach is ever worked out.
  • dj_load_init function
    • Core, PL
    • Used to call dojo.hostenv.makeWidgets() and dojo.hostenv.modulesLoaded()
  • dojo.hostenv.makeWidgets function
    • Core
    • Parses document for widgets.
  • Code block for: //easier and safer VML addition. Thanks Emil!
    • Does this need to be done here, or can it be done as part of packages that need this?
  • dojo.hostenv.byId
    • Alias for dojo.byId. Only used once in this file. Just convert to dojo.byId.
  • dojo.byId function
    • Core
    • many
  • dojo.hostenv.byIdArray (and its alias, dojo.byIdArray)
    • Not used anywhere in the dojo source. Remove it? If not remove it, make it part of dojo.byId?

Attachments (0)

  File By Size Attached Ver.