Add priority ordering to loaded extensions in each category;
this allows control over the resulting order of extensions
acquired and used within the application. WTD-590
Expose angular as a dependency which can be included
from AMD-style modules, utilizing the extensions to
the framework layer added to support exposing libraries
from bundles. WTD-568.
Complete tests for the RequireJS configurator, used to
expose libraries beyond bundle boundaries (and, related,
to provide shims for non-AMD libraries.) WTD-568.
Add a configuration step (as part of the resolve phase)
to the framework layer, where bundle-defined paths and shims
are passed to RequireJS configuration. This permits both
the use of non-AMD modules and the exposure of libraries
across bundles. WTD-568.
Add un-minified Angular and source mappings to aid
in debugging infinite digests. These are occurring
when leaving Edit mode, e.g. after editing a Layout,
so this is needed to complete transition of the
Layout object type. WTD-535.
Remove extra semicolons from PartialConstructor to
satisfy JSLint during code style check of command
line build; these were introduced during changes
to PartialConstructor to support property retention,
WTD-572.
Add spec to verify that static properties exposed by
extension constructors remain visible after these
have been converted to partial constructors. These
static methods have various uses, such as providing
appliesTo methods to classes where pre-instantiation
filtering is useful. WTD-572.
Add an (empty) bundle definition for the framework
component. This has the practical effect of avoiding
404 errors in the console log, since platform/framework
is included in bundles.json (the set of active bundles)
in order to ensure detection by the test framework.
This also provides a place for possible future
extensions provided by the framework itself.
WTD-572.
Bring in changes from 'sandbox' branch. These include:
* Reconfiguring require's baseUrl such that relative
paths work as expected in define call dependencies.
Previously this only worked as expected in the
framework bundle, since data-main points there.
* Add support for a 'constants' category of extension,
to define application constants from bundles. This
allows services to treat static values (such as
persistence URIs) as injectable dependencies.
* Various assurances that properties from extension
definitions will be exposed upon resolved
implementations, even after partial construction.
WTD-572.
Remove temporary script file (introduced for initial
build/repository setup to illustrate naming conventions
and test declaration) from framework sources.
Completes implementation of framework layer for
WTD-518.
Remove spec for Constants.js (only constants are defined
here, and there is no particular use to verifying their
existence; also, implicitly tested by specs for code
which uses these constants.) WTD-518
Initial implementation of the service compositor, which
is responsible for registering components which follow
the provider-aggregator-decorator pattern as named
services within Angular. WTD-518.
Fix the replicated behavior of the new operator in the
partial constructor such that it accepts factory-style
constructors (which will be the norm according to
current code style standards.) WTD-518.
Satisfy dependencies on empty extension sets when
necessary; extensions which depend on extension
categories which do not exist then get an empty
array. WTD-518.
Add tweaks in framework which fix errors which
were preventing controller registration. This
includes maintaining the type of controllers as
functions, even after decorating with information
from the extension. WTD-518.
Fix error in CustomRegistrars; return a function when
creating general-purpose registration code for
Angular built-ins which follow the normal pattern
(directives, controllers, services...)
WTD-518.
Handle the iteration over extensions which have a
custom registration mechanism (directives, services)
at the same level that general registration is handled.
WTD-518.
Continue implementation of registration phase of framework layer.
Begin adding some custom registration behavior for specific
Angular concepts, such as services and directives. WTD-518.
Begin implementation registration phase of framework
layer initialization process. This phase is responsible
for registering resolved extensions with Angular, in a
manner than individual extensions can later request
dependencies from. WTD-518.
Initial implementation of class responsible for
resolving extensions (that is, loading modules
associated with defined extensions.)
Also, add methods to Bundle and Extension classes
to support logging performed during the extension
resolution phase. WTD-518.
Begin work on extension resolution phase of
the framework layer. WTD-518.
Introduce an implementation loader which wraps
RequireJS, and a skeleton class for extension
resolution.
Continue implementing classes which represent fundamental
concepts within the framework layer. WTD-518.
In particular, add methods which will be useful during the
extension resolution phase of framework start up.
Begin implementing the bundle loader component of the
framework layer, responsible for taking a list of
included bundles and exposing their contents in a
useful manner. WTD-518.
Add main point-of-entry script for framework layer; performs
only minimal tasks of loading framework dependencies
and demonstrating that bundle list can be loaded
using these. WTD-518.
Add Promise polyfill to version control. Promise objects
are included in ECMAScript 6 and browser support is
present, but non-universal. Using the polyfill approach
permits the use of Promise directly throughout the
application without relying on bleeding-edge browser
support.
Promises are useful at the framework level particularly
because of the number of asynchronous calls made when
assembling bundles. Framework layer is WTD-518.
Add clarifying comments to temporary files, to
ensure they are distinguishable as placeholders.
Part of developing project folder structure and
build for WTD-519.
Add libraries for Angular and Require. This expands
folder structure to support initial build (WTD-519)
and also directly supports implementation of a
framework layer (WTD-518).
Add general structure for Open MCT Web, including
top-level and second-level directory structure.
README files are included to explain the role of
each directory; markdown is used to allow for
richer display when viewer support is present.
WTD-519.
