This uses GNU Octave's CSS, which formats it like a printed manual
using a modern style. It's certainly an opinionated style, but at the
very least, the width is important.
* Makefile.am (MAKEINFOHTML): Include CSS reference.
* liza.css: Add stylesheet.
This code assumed that no classes would be removed that were _not_
added by #addClass. Well, that's false.
* src/ui/styler/FieldStyler.js (removeClass): Consider both spaces and
boundary preceding class name.
* test/ui/styler/FieldStylerTest.js: Add test case.
Classifications often yield scalar results. Since those results are
used directly in the diff, we have the situation where the expected
diff format (an array) is not provided. Consistent with the rest of
the system, we should consider a scalar to affect every index.
* src/validate/ValidStateMonitor.js (_checkCauseFix): Consider scalar
diffs to affect every index when checking for fixes.
* test/validate/ValidStateMonitorTest.js: Add test.
Previously, the system relied on the preStagingUpdate StagingBucket
event to do this implicitly, but that is no longer kicked off when
the diff doesn't produce any bucket changes.
* src/client/Client.js (_createProgram) [dapi]: Clear validation
failures on dapi fieldLoaded.
The intent of this is to allow for clearing errors after fields
load (e.g. a "field loading" message if the user attempts to continue
past the step when a field hasn't yet finished loading).
* src/dapi/DataApiManager.js (getApiData): Emit fieldLoaded after
request completes.
* test/dapi/DataApiManagerTest.js: Add test case.
DEV-2299
This was not properly chain the promises---it was always chaining on
the original _pending (so, the first request) and never clearing
_pending after that point.
* src/validate/DataValidator.js (_onceReady): Properly chain.
* test/validate/DataValidatorTest.js: Updated test. Don't ask.
This does two things:
- Ensures previous validation requests are complete before
processing another, preventing internal state from being screwed
up; and
- Prevents empty diffs from triggering staging bucket events, which
is both a performance benefit and stops ValidStateMonitor from
getting confused and immediately marking failures as fixed in
certain circumstances.
This fixes accidental global variables and enables strict mode to
prevent it in the future.
* src/bucket/StagingBucket.js: Enable strict mode. Use const/let where
appropriate instead of var.
Since changes trigger any event observers---which can be
expensive---it is ideal to ignore sets that do not result in any
changes to the bucket.
This also resolves issues with systems that are confused by empty
diffs.
* src/bucket/StagingBucket.js
(_hasChanged): Add method.
(setValues): Use it.
* test/bucket/StagingBucketTest.js: Add test case.
DEV-2299
Since we maintain state (as a kluge for the time being to integrate
with the rest of the system), we need to be careful to protect against
concurrent requests that might mess with it before the original
request is complete.
* src/validate/DataValidator.js
(validate, updateFailures): Hold concurrent requests.
(_onceReady): Add method.
* test/validate/DataValidatorTest.js: Add tests.
This allows for testing assertions. It's fairly primitive, but will
work for the time being.
* src/test/README: Add file.
* src/test/program/DummyClassifier.js: Add module.
* src/test/program/Program.js: Add class.
* src/test/program/util.js: Add module.
In practice, not clearing the store and allowing it to use previous
state has the effect of instantly "fixing" failures if there happens
to be more than one validation call.
This was a log of debugging for a one-line change.
* src/validate/DataValidator.js (_populateStore): Always clear store.
* test/validate/DataValidatorTest.js: Add test.
DEV-2299
I updated DataValidator but never updated the caller. Damnit. It's
an unfortunate side-effect of dynamic, loosely typed languages and
mitigating it requires what should be boilerplate functional tests (in
this case---functional tests are useful for many other integration
aspects).
* src/event/FieldVisibilityEventHandler.js
(handle): Use updated DataValidator#clearFailures API, which has
a different descriptor format.
* test/event/FieldVisibilityEventHandlerTest.js: Update test.
Previous work was done to have field errors clear when any
classification in the assertion stack changes. The last remaining
piece was to have field errors clear when the field itself is no
longer applicable.†
- Handling in `Client` was replaced with
`FieldVisibilityEventHandler`. The event system already existed.
- `DataValidator` and `ValidStateMonitor` just needed the ability to
clear specific fields (`#clearFields`).
† Technically the "hide" in liza means "not applicable"; I've been
using that new terminology, but this event can't be renamed right now
because it's so heavily used.
This is a separate program of sorts that sits alongside and hooks the
Client.
* src/client/debug/AssertionClientDebugTab.js: Add class.
* src/client/debug/BucketClientDebugTab.js: Add class.
* src/client/debug/CalcClientDebugTab.js: Add class.
* src/client/debug/ClassifyClientDebugTab.js: Add class.
* src/client/debug/ClientDebug.js: Add class.
* src/client/debug/ClientDebugDialog.js: Add class.
* src/client/debug/ClientDebugTab.js: Add interface.
This thing is an ugly monstrosity that has witheld some pretty rough
development times. As code is touched, it is being removed.
This depends on many things not yet in the liza repo; they'll be added
in time.
These classes were changed slightly to work within liza (e.g. paths).
* src/client/Client.js: Extract from rating-fw
as of 5d4019f1973f9271f4b1bd24ce1f55b56ccda09e.
* src/client/ClientDependencyFactory.js: Extract from rating-fw
as of 5d4019f1973f9271f4b1bd24ce1f55b56ccda09e.
LoVullo dropped support for IE<9, so getters can now be used to
lazy-load modules.
This also means that, during the transition from LoVullo's internal
rating-fw repo to liza, and broken require paths (program/, mainly)
will not cause problems unless the module containing those requires is
explicitly requested.
* tools/gen-index.js: Generate getters.
Mike Gerwitz