Browse Prior Art Database

Feature condition branching in expanded dependency lists

IP.com Disclosure Number: IPCOM000235841D
Publication Date: 2014-Mar-26
Document File: 2 page(s) / 32K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a new technique of feature condition branching whereby both of the dependency trees of a conditionalized dependency, when the feature value is undefined, can be used to avoid truncated dependency expansions, thereby avoiding unnecessary additional resource requests.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 2

Feature condition branching in expanded dependency lists

The method described herein expands upon a previously described method for aggregating nested resource dependencies, by expanding dependency lists defined

within the resources. It addresses the case of explicit and expanded resource dependencies that are conditionally included based on the availability of some feature.

The novel contribution is a technique of feature condition branching whereby both of the dependency trees of a conditionalized dependency, when the feature value is

undefined, can be used to avoid truncated dependency expansions, thereby avoiding unnecessary additional resource requests.

The Dojo Asynchronous Module Definition (AMD) loader provides the 'dojo/has' loader plugin, which allows AMD resource dependencies to be conditionalized based

on the availability of a feature. The plugin is specified as part of the module identifier (ID). Consider the following example:

define(["dojo/query", "dojo/has!foo?fooimpl:barimpl"], ...

In the above example of the define() call of an AMD module, the module is defined to depend on the modules "dojo/query" and one other module. If the feature 'foo' is true, then the other dependency is the module 'fooimpl'. If the feature 'foo' is false, then the other dependency is the module 'barimpl'.

The implication of conditionalized dependencies such as this, as it relates to server-side dependency expansion, is that if the specified feature is defined (either true of false) at the time of server-side expansion, then the server can select which module to include and, hence, which module's dependency tree to follow when expanding nested dependencies. If the feature has not been defined (e.g., because the feature will be defined by code that has not yet been executed on the client), then the server cannot include the nested dependencies of either choice in the expended dependency list. When the client code calls require using the expanded dependency list that does not include expanded dependencies for the conditionalized modules, then the loader makes one or more additional follow-on requests for resources as nested dependencies for the conditionalized modules are discovered through the loading process.

In the loader module IDs, the '!' character separates the loader plugin ID (dojo/has in this case) from the module ID. It should not be confused with its traditional meaning of the logical NOT operator in most programming languages.

The novel technique avoids the additional, follow-on, requests by expanding both branches of a conditionalized dependency when expanding nested dependencies.

Consider that in the previous example, the module fooimpl has a declared dependency on foodep1 and foodep2,...