Move spec for view switcher from bundle
platform/commonUI/browse to bundle
platform/commonUI/general to reflect refactoring
to simplify usage in other places (including in
Layouts, which are being transitioned for
WTD-535.)
Refactor view switcher to simplify it; treat it
as a representation of a domain object that modifies
an ng-model. This simplifies reuse, e.g. in frames
within a layout. WTD-535.
Add a controller for composite controls; this is used
to flag contained controls as required when they have
been partially filled in (to treat entering one of two
such fields as invalid.) WTD-593.
Provide initial empty arrays for type properties that
are array-like; this is needed to support two-way data
binding for composite controls. Part of ongoing integration
of forms component, WTD-593.
Add placeholder spec for the LocatorController, introduced
to support forms used from the Create menu. Part of ongoing
integration of forms bundle, WTD-593.
Use ng-model when communicating state to/from the
tree in browse mode. This will simplify implementation
of the Locator control, which also uses a tree, but
which should not set navigation state. WTD-593.
Reorganize templates associated with the Create menu in
preparation for adding the Locator control, used to
specify the destination folder for object creation.
WTD-593.
Hide dangling underscores; JSLint considers these a problem
and the command line build fails as a consequence when they
are present directly in the code, but CouchDB provides these
so we cannot avoid them entirely. So, hide them behind
variables and use []-style lookup.
Concludes transition work for the CouchDB persistence adapter,
WTD-537.
Fill in JSDoc for the CouchDB adapter which provides
the ability to persist domain object models. Part of
ongoing transition of the platform/persistence bundle,
WTD-537.
Separate CouchDocument (used to wrap a domain object model
with metadata suitable for persistence to CouchDB) into
its own script, to simplify testing and maintenance.
Ongoing transition of Couch persistence, WTD-537.
Fill in specs for ScrollingListController, and for
the specific Column types that support it. Separate
out the code that produces actual rows in order to
improve testability and maintainability. WTD-534.
Bring in scrolling list view from the sandbox branch
in preparation for clean up, testing, and integration
to complete transition of scrolling list views,
WTD-534.
Place elements of the PlotController into a separate
directory inside of the source folder for the plot
plug-in, in preparation for review and integration.
Part of ongoing plot transition to Angular, WTD-533.
Bring in initial state for the platform/telemetry
bundle, which provides general-purpose telemetry
conventions and infrastructure to support creating
domain objects which expose telemetry data.
WTD-575.
Implement date time controls up to the point that
they validate, and information (albeit not the right
information) propagates back up to the containing
form. WTD-530.
Simplify select control's interaction with the model;
only store the value associated with the option, not
the name (which is just displayed for the user.)
WTD-530.
Add remaining platform form controls; amend mct-form
and mct-control directives to better communicate state.
Begin working on problem of communicating validation
back out of the form. WTD-530.
Initial minimal working implementation where a
two-way binding between form and form user is
observable.
Notably, change ng-options to options, since
ng-options is terminal (it breaks mct-control).
WTD-530
Bring in previous work on the forms component; this includes
transitioned versions of specific form elements, and the
mct-form direction which generates these. WTD-530
Fix FullscreenActionSpec such that it will execute on
command line; the global screenfull dependency behaves
differently during attempts to spy on methods from
the command line build, so replace it entirely.
Concludes work on WTD-574 in preparation to submit for
review.
Fix a defect in the Save/Cancel buttons in Edit mode
that was causing the first click to be missed; this
was due to Angular's inability to detect when a
native promise (as opposed to one from ) had been
resolved.
Since the Editor capability is introduced indirectly
and is a few degrees of separation removed from
the declared extension layer (where we would be able
to get a reference to ), and all we need to do is
make something look Promise-like, a convenience
function to do this is added.
Part of ongoing transition of common user interface
elements, WTD-574.
Fill in specs for CreationService, which supports the
Create action, which, in turn, is included to support
the Create button in Browse mode. Part of the transition
of common user interface elements for WTD-574.
Fill in spec for the controller which maintains a set of
applicable and selected view options to populate the
view switcher. Part of Browse mode and, in turn, part
of the common user interface elements that are being
transitioned for WTD-574.
Add in-line docs for bundle platform/commonUI/browse,
which implements Browse mode, one of the common user
interface bundles being transitioned in WTD-574.
Add JSDoc to Create-related classes and remove the
UUIDService (replaced by third-party lib) to reduce
amount of code to cover and prepare for code review,
as part of ongoing transition of common user interface
elements, WTD-574.
Fill in specs for bundle platform/commonUI/dialog,
which provides the ability to show dialogs. One
of the common user interface elements being transitioned
for WTD-574.
Skeleton specs for bundle platform/commonUI/dialog,
responsible for displaying dialog overlays. Part of
ongoing transition of common user interface elements
for WTD-574.
Refactor bundle platform/commonUI/dialog such that
the concerns of showing dialogs (including showing
a single instance thereof) and managing changes to
the DOM are more cleanly separated. This simplifies
testing and satisfies code style guidelines for
this bundle, in preparation for its inclusion among
common user interface bundles to be transitioned
in WTD-574.
Add in-line documentation to the dialog service,
exposed by bundle platform/commonUI/dialog, one
of the common user interface bundles being
transitioned for WTD-574.
Add in-line documentation for actions that are introduced
by the bundle platform/commonUI/edit, which introduces
Edit mode. One of the common user interface bundles being
transitioned for WTD-574.
Add specs for remaining capabilities and capability
wrappers employed by Edit mode. Completes coverage
for bundle platform/commonUI/edit, which is being
transitioned along with other commonUI bundles in
WTD-574.
Add specs for the save and cancel conclude-editing
actions, part of bundle platform/commonUI/edit
(Edit Mode) which is transitioned among the various
common UI bundles. WTD-574
Amend ActionGroupControllerSpec (introduced for WTD-574,
transition of common UI elements) such that it handles
the case where no action capability is defined.
Add in-line documentation to TreeNodeController, and update
glossary with some clarifying definition.
Additionally, change name from tree-item to tree-node for
consistency.
Part of ongoing transition of commonUI bundles, WTD-574.
When a dialog is already showing, act as if the
user input was cancelled and show a warning.
Part of ongoing transition of common user interface
bundles for WTD-574.
Add JSDoc and clarifying comments to the CreateMenuController,
which is responsible for maintaining an up-to-date set of
Create actions for a given domain object. WTD-574.
Add a general-purpose controller for UI elements which
have 'click-away' behavior; that is, they should be
deactivated on document clicks.
This generalizes existing behavior added for the Create
menu, such that it may be used on other, similar menus
and UI elements.
Part of ongoing transition of common user interface
components, WTD-574.
Fix extension definitions related to the refactoring
of GestureProvider out of the mct-representation
directive. Completing work on the initial version
of the representation bundle, WTD-521.
Add spec for the mct-representation; separate out gesture
attachment to improve testability and increase cohesion.
Part of ongoing initial authorship of representation
component, WTD-521.
Add spec for ContextMenuGesture, which exposes a menu
of applicable actions for objects when it is performed.
One of the built-in gestures supported by the
representation component, WTD-521.
Work around quirk of require; it does not like to see
the same script twice with and with a .js, so remove
the .js extension from the bundle definition. WTD-573.
Add JSDoc for the domain object wrapper used to
expose a 'context' capability; part of
ongoing documentation to meet code standards in
platform/core in preparation for integration.
WTD-573.
Add JSDoc for remaining action service components
(ActionProvider and LoggingActionDecorator) to
satisfy code standards in the platform/core bundle,
for WTD-573.
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.
