* src/ui/step/GeneralStepUi.js (scrollTo):
Will now abort after each error rather than falling through.
Visibility error message will now show field index.
* test/ui/step/GeneralStepUiTest.js: Added respective test cases
This defaults to the global jQuery just so we don't break
everything (BC); that'll be removed in the future.
* src/ui/step/GeneralStepUi.js (__construct): Accept jQuery.
(setContent): Use jQuery instance passed via ctor
This can now be handled with the existing formatters, specifically the
MultiDimension trait. Specifically, multitext simply handled the
styling of vectors.
* src/ui/ElementStyler.js (_answerStylers): Remove multilimit
This will simplify, through composition, a number of other
validator-formatters.
* src/validate/formatter/MultiDelimited.js: Added
* test/validate/formatter/MultiDelimitedTest.js: Added
This adds a great deal of flexibility through composition via trait
stacking.
* src/validate/formatter/UnorderedList.js: Renamed from
UnorderedListFormatter; now a trait.
* test/validate/formatter/UnorderedListTest.js: Renamed from
UnorderedListFormatterTest and adjusted to instantiate trait.
These have been refacored from the original: rather than abusing what is now
the PatternFormatter, it is now its own class.
* src/validate/formatter/UnorderedListFormatter.js: Added.
* test/validate/formatter/UnorderedListFormatterTest.js: Added.
This allows overriding for testing (and is a proper abstraction); eventually
this will be moved out of this class entirely.
* src/ui/step/GeneralStepUi.js (getAnswerContext): Added
Number of methods updated to use.
This is just to enable some sort of testing without instantiating the entire
class and navigating a maze of methods.
* ui/step/GeneralStepUi.js (answerDataUpdate): Added
(_processAnswerFields): Extracted function into answerDataUpate
* src/validate/ValidStateMonitor.js (mergeFailures):
Another error on a field that previously failed will no longer overwrite the
previous failure, which caused issue when the causes changed (leaving fields
potentially unfixed).
* test/validate/ValidStateMonitorTest.js: Respective tests added.
* src/validate/Failure.js (__construct): Takes an array of causes.
(getCauses): Now returns an array of causes.
* src/validate/ValidStateMonitor.js: Recognize fixes on array of causes.
* test/validate/FailureTest.js: Updated
* test/validate/ValidStateMonitorTest.js: Updated
This maintains BC with the old string-based system.
* src/validate/ValidStateMonitor.js (_getCause): Added.
(detectFixes): Consider failure cause if available when checking for fixes.
This solves the problem of trying to show/hide indexes that do not even
exist on the DOM.
There are no tests for this due to the complexity of the parent; refactoring
is needed. :(
* src/ui/group/FlatGroupUi: Added
This will allow it to know when a request needs to be re-made at a later
time.
* src/dapi/DataApiManager (fieldStale, isFieldStale): Added
(fieldNotReady): Check stale status of field
It might be the case that we may want to post raw data in the future; in
fact, I can guarantee it. We'll cross that bridge when we come to it.
* src/dapi/http/XhrHttpImpl.js (openRequest): Set ContentType header
on POST
* test/dapi/http/XhrHttpImplTest.js: Modified accordingly
The intent is to ultimately replace ClientFieldValidator with this and
individual validators that interact with it.
* src/validate/ValidStateMonitor.js: Added
* test/validate/ValidStateMonitorTest.js: Added
This allows #validate to be used generically for any type of validation, not
just change events.
* src/validate/ClientFieldValidator.js (validate):
Accept and propagate all bucket data to `validate` event listeners.
* src/validate/ClientFieldValidator.js (monitor): Remove
This just concerns itself with something that it should be concerned about;
let the caller handle monitoring, now that we have a #validate method.
* src/validate/ClientFieldValidator (validate): Added
Extracted logic that previously was exclusive to #monitor; that method will
now simply invoke #validate.
* src/ui/field/DomField.js (queryElement): {Error=>DomFieldNotFoundError}
when a DOM element cannot be located for the field.
* src/ui/field/DomFieldNotFoundError.js: Added
element.style is not supported as an lvalue in IE<9.
All the rest of the sane world that doesn't support IE<9 should be laughing
at me in pity right now.
* src/ui/styler/NaFieldStyler.js (hideField):
Use HTMLElement#setAttribute instead of HTMLElement#style as an lvalue
* test/ui/styler/NaFieldStylerTest.js: Modify test cases to check for
invocation of setAttribute
* src/ui/styler/NaFieldStylerAnimation (showField):
The 'display:none' style was retained in certain circumstances after
animation in IE; this fixes that.
Yes, this is a mess; I'm pretty much out of time now.
* src/ui/group/GroupUi.js (doShowField, doHideField):
Use field styler
* src/ui/group/TabbedGroupUi (doShowField, doHideField):
Defer to supertype
I didn't really want to add this back in, but others in the group
thought that change might be bad for users. This animation thing is
just so sloppy, I think.
* src/ui/styler/NaFieldStylerAnimation.js: Added
This solves styling and DOM mutation issues. For now.
* src/ui/field/DomField.js (queryElement, updateElement): Added
(_getElement): Extracted into queryElement and updated to re-query DOM each
time, returning last match if not found.
(applyStyle, revokeStyle): Defers style applied predicate to style itself
Field stylers now determine whether they've been applied to the target field
on their own, which solves the problem of the system getting out of sync.
* src/ui/styler/ErrorFieldStyler.js (isApplied): Added
* src/ui/styler/FieldStyler.js (isApplied): Added
* src/ui/styler/NaFieldStyler.js (isApplied): Added
* test/ui/styler/NaFieldStylerTest.js: Test for #isApplied
This is necessarily primarily for a specific case: option elements in IE,
which cannot be styled. >:O
This implementation is not complete: we want to re-attach the field at the
same position it was at before it was detached. This might not be
trivial---imagine if its sibling was also detached.
* src/ui/styler/NaFieldStyler.js (isSubField): Receive field instead of
element (to check parent)
(applyStyle, revokeStyle): Detach and re-attach field from/to DOM
respectively
* test/ui/styler/NaFieldStylerTest.js: Associated tests
* src/ui/field/DomField.js (getParentElement):
Renamed from getParent. Cache parent element in memory so that we have a
reference for re-attaching fields to the DOM.
(getParent): Public API addition; call getParentElement
* src/ui/group/TabbedGroupUi.js (doShowField, doHideField):
Return from method after setting deferred operation. This previously
did not fail because jQuery didn't care if operations are not
performed on field matches.
* src/ui/field/DomField.js (getContainingRow): Return self if DT or DD
Certain types of elements (e.g. statics) are compiled such that the direct
reference is the row itself.
* src/ui/ElementStyler.js: Added
* src/sort/MultiSort.js: Removed ElementStyler liberation todo
* src/ui/field/DomFieldFactory.js: Same
* src/ui/step/GeneralStepUi.js: Same
* src/ui/step/StepUiBuilder.js: Same
This existed when the framework was very long, and has managed to survive
numerous refactoring attempts; it used to be a small class abstracting
element styling, and it has had crap thrown into it ever since, partially
due to time constraints. It needs to go away.
* src/ui/GroupUi.js (getFieldElements): New method
(showField, hideField): Use GroupUi#getFieldElements
* src/ui/group/TabbedGroupUi (showField, hideField):
Use GroupUi#getFieldElements
The `AccordionGroupUi` was not liberated, because it is my intent to
eliminate it---I did not agree with its needless addition to begin with. If
we do end up keeping it, then it will be liberated as well.
This allows us to begin development (and testing) of StepUi subtypes without
having to worry about the convoluted crap that GeneralStepUi is doing.
Specifically, all the jQuery stuff needs to go.
This is crazy, but LoVullo Associates still supports browsers as far back as
IE7, meaning that we need to maintain ES3 support; that will hopefully
change soon.
The Data API is being heavily refactored and tested; while moving files into the
Liza repository, I noticed some inefficiencies with the design. These are being
heavily improved upon.