I've long been opposed to adding this delay, but a proper fix (for deferred,
async rating) that meets the needs of our current project will require
changes that I don't have time to take on for a little while. As such, this
will be a temporary solution for hopefully no more than a month's time.
* src/client/Client.js (_initBeforeLoadHook): Pass value to event in
addition to step id.
* src/client/event/RateEventHandler.js: Implement delay.
DEV-6145
The quicksave feature was added back in 2011 when the framework was somewhat
unstable---we were taking calls from users and it wasn't a pleasent
experience to tell them that they had to refresh the page to work around
some issue with bad state, and lose all unsaved data.
This feature is now more trouble than it's worth, since it causes a number
of bugs and can even cause data corruption. If this is reintroduced in the
future, I'd prefer it be done by periodically saving quote state after every
or a few bucket modifications, to permit Meteor-like features.
This keeps the feature available on the client as a heartbeat for quote
locking; this can be removed in the future when we handle distributed
locking.
* src/client/Client.js (_changeQuote): Stop setting quicksave data from
request.
(_mergeQuickSaveData): Remove now-unused method.
(_createUi): Stop merging quicksave data on render.
(saveStaging): Add note that this method is now only used as a heartbeat.
* src/client/quote/ClientQuote.js (saveStaging): Add comment indicating that
this is now used for a heartbeat.
(setQuickSaveData, getQuickSaveData): Remove methods.
* src/quote/BaseQuote.js (_quickSaveData): Remove field.
(setQuickSaveData, getQuickSaveData): Remove methods.
* src/server/Server.js (initQuote): Do not create or initialize quicksave
data.
(handleQuickSave): Remove method.
* src/server/daemon/controller.js (doRoute): Return empty reply without
processing quicksave data. Continue touching session to retain quote
lock.
* src/server/db/MongoServerDao.js (saveQuote): Do not clear quicksave.
(quickSaveQuote): Remove method.
Prior to this change, a single generic message was always shown simply
stating that the quote had been locked. These changes now allow for
different messages to be displayed in different circumstances.
Forward validation failures were never updated to use the new Failure
object, so they ended up showing the default message. The problem was that
`ui.invalidateForm' was replacing the Failure object with a new one with an
empty message.
This change just does the same thing as the change and save events.
* src/client/Client.js (_forwardValidate): Invoke `#_genValidationMessages'
and `_dataValidator.updateFailures'. Stop calling `ui.invalidateForm'.
* src/client/ClientDependencyFactory.js: Remove old AccordionGroupUi
require, add new one.
* src/ui/group/AccordionGroupUi.js: New class.
* src/ui/group/GroupUi.js (postAddRow): Make virtual.
The `*_label' fields were not being properly set because they were being
considered just as every other expanded field, which is subject to other
considerations to ensure that we do not overwrite user data. Label fields,
on the other hand, _must_ always be set whenever the value changes, and are
_not_ modifiable by the user.
This codifies that `_label' assumption that I would like removed in the
future, but time does not permit that sort of refactoring right
now. Ideally, labels would be treated generically like any other expanded
field and have an attribute set of them that would change their expansion
behavior.
* src/client/dapi/DataApiMediator.js (_updateFieldData): Pass label field id
to `_populateWithMap'.
(_populateWithMap): Use it to always populate the label field when the key
matches, ignoring the other expansion criteria that would inhibit it.
* test/client/dapi/DataApiMediatorTest.js: Update test accordingly.
* src/dapi/DataApiManager.js (triggerFieldUpdate): Provide id to
`_genUiFieldData'.
(_genUiFieldData)[label_id]: New field. Return it as part of the return
object's `label_id' field.
DEV-4077
This further highlights that we probably should not be handling this
here. We want to ensure that we check the state of the bucket right before
we're about to do option setting, otherwise we could be in an inconsistent
state (looking at old data).
* src/client/dapi/DataApiMediator.js (_updateFieldData): Check bucket after
stack clears (along with all other operations).
Allowing the stack to clear ensures that (in practice) DelayedStagingBucket
is given a chance to do necessary processing before data are requested from
it by bucket hooks as a result of _this_ invocation, which in turn
results (in some cases) in infinite recursion.
* src/client/dapi/DataApiMediator.js (_updateFieldData): Allow stack to
clear before invoking `quote.setData'.
* test/client/dapi/DataApiMediatorTest.js: Test respectively.
DEV-3257
Without this, we have a BC break.
* src/client/Client.js (_init): Default program.dapimap to DataApiMediator
instance to an empty object to maintain BC.
* src/client/dapi/DataApiMediator.js (_populateWithMap): Update
docblock. Ignore field during expansion if it would overwrite an
existing value.
* test/client/dapi/DataApiMediatorTest.js: Update tests data to include
values for all bucket fields, not just `name'. Add test for new
condition.
DEV-3257
[*] You should not use this commit directly since this may wipe out data in
fields the user has changed. See future commit where this situation is
properly handled.
* src/client/Client (_init): Provide dapimap to DataApiMediator instance.
* src/client/dapi/DataApiMediator.js
(_dapi_map): New field.
(constructor): Accept dapimap. BC break (which is okay, since this is
still part of a topic branch). Assing to _dapi_map. Update docblock.
(monitor): Bind `dapi_manager' to first argument of handlers.
(_updateFieldData): Accept `dapi_manager' as first argument. Use
`_populateWithMap' to generate additional update data.
(_populateWithMap): New method.
(_clearFieldFailures): Accept `dapi_manager' as first argument.
* src/dapi/DataApiManager.js: Update copyright year.
(getDataExpansion): Return empty object (consistent with interface) rather
than `undefined' when field value is undefined. Use
{Error=>MissingDataError} when field data are missing. Throw instead of
emit. Fix missing comma in var declarations.
* src/dapi/MissingDataError.js: New class.
* test/client/dapi/DataApiMediatorTest.js: Update test data to test field
expansion. New test against ignoring field expansion when data are not
available. Update Sut constructors of other tests for new dapimap
parameter.
DEV-3257
This extracts existing code from Client and adds tests. The glue code is
far from ideal and highlights the amount of work needed to decouple Client
from so many parts of the system.
* src/client/Client.js (_dapiManager): New field.
(_init): Use DataApiMediator.
(_createProgram): Assign `_dapiManager' (this is not at all
ideal). Remove hooks from it: fieldLoading, updateFieldData,
clearFieldData.
* src/client/ClientDependencyFactory.js (createDataApiMediator): New alias
to DataApiMediator constructor.
* src/client/dapi/DataApiMediator.js: New class.
* test/client/dapi/DataApiMediatorTest.js: New test case.
DEV-3257
Before this change, since `undefined' is encoded as `null' when serialized,
there was no way for the server to disambiguate between unmodified values
and a truncation point. For example:
[ undefined, undefined, null, null, null ]
The above array represents two unmodified and three removed indexes. But
this is serialzed into JSON as:
[ null, null, null, null, null ]
It isn't possible for the server to determine what the truncation point is
from that diff. The solution is to therefore truncate the array _before_
sending it to the server, providing a trailing null to indicate that a
truncation has occurred:
[ null, null, null ]
The above means that the first two indexes are unmodified, and that index 2
and later should all be truncated.
* doc/client.texi (Saving to Server): New section.
* src/client/transport/XhttpQuoteTransport.js (_truncateDiff): New method to
perform truncation.
(getBucketDataJson): Use it.
* test/client/transport/XhttpQuoteTransportTest.js: New file with respective
test case.
* src/client/Client.js (_defaultId): New property.
(__construct)[default_id]: New parameter. Set `_defaultId'.
(_getProgramId): Use `_defaultId' if not found in URL.
* src/ui/nav/HashNav.js (_initUrl): Do not require leading program id.
This technically worked fine before with our URL scheme, but that is not
guaranteed to be the case generally.
This is something that managed to slip by (but not unnoticed) for almost
exactly one year to this day (028606242a). It
can only be reproduced by changing classes that result in visibility changes
differing on the same field by index. The issue hides itself on first
load (because all fields are shown by default) and on refresh.
The problem is that, when one index shows a field but another hides it, the
hide overrode the show indexes, so only the hide took place.
* src/client/Cmatch.js (markShowHide): Make virtual. New implementation to
support concurrent show/hide.
(_handleClassMatch): Use it.
* test/client/CmatchTest.js: New test.
* npm-shrinkwrap.json: ease.js v0.2.{8=>9}.
This is to give us a fairly easy means of testing this logic for a bugfix.
This refactoring also obviates a pretty nasty bug; see docblock.
* src/client/Cmatch.js (_handleClassMatch): Extract show/hide marking.
(markShowHide): New method.
This makes the minimal number of changes necessary to ensure that all object
references remain available. It is a mess.
And despite moving all of this, Client is still a massive clusterfuck.
* src/client/Client.js (system): Add import.
(_cmatch): Now references new Cmatch class instance.
(_cmatchHidden, _classMatcher): Remove fields.
(_forceCmatchAction): Rename to `forceCmatchAction'.
(_hookClassifier, _postProcessCmatch, _cmatchVisFromUi, _handleClassMatch,
_mergeCmatchHidden, _clearCmatchFields): Extract methods. Update
references as necessary.
(getCmatchData): Remove unused method.
(_handleError): Rename to `handleError' to make accessible to
Cmatch. Update references.
* src/client/ClientDependencyFactory.js (FieldClassMatcher): Remove import.
(createFieldClassMatcher): Remove method. See `system/client'.
* src/client/Cmatch.js: New class.
* src/system/client.js (Cmatch, field): Add imports.
(cmatch): Add export.
All of the old events have been removed!
* src/client/Client.js (handleEvent): Remove remainder of old system (after
last commit, all that was left was error handling). Correct docblock.
The `set' event already existed---this merely extracts it into its own
handler.
* src/client/Client.js (handleEvent): Extract `set' handler.
* src/client/ClientDependencyFactory.js (createClientEventHandler): Add
`set'.
* src/client/event/ValueSetEventHandler.js: New class.
* test/event/ValueSetEventHandlerTest.js: Associated test case.
This matches the behavior of assertions.
This needs to be refactored into an even handler.
* src/client/Client.js (handleEvent)[set]: Use last available index.
These animations are ugly and slow when there are many questions on a
step. I've wanted them gone for quite some time, and now we don't have a
disagreement among developers.
* src/client/ClientDependencyFactory.js (createNaFieldStyler): Remove
NaFieldStylerAnimation mixin.
* src/ui/styler/NaFieldStylerAnimation.js: Remove trait.
This is necessary to truncate on index removal; otherwise, it's not possible
to remove indexes through the editor.
* src/client/debug/BucketClientDebugTab.js (_getStagingButtons): Append null
on value change.
This mixes in support for non-terminating nulls. It would have been
nice to handle that in a separate commit for clarity, but the
refactoring came as a consequence of trying to provide a working
implementation.
Various inconsistencies and subtle bugs in unlikely situations have
been fixed by this, including modifying objects passed as arguments to
various methods, and inconsistent handling of diff data.
Changes are more consistently recognized. Perhaps the most noticeable
consequence is that moving between steps no longer prompts to discard
changes---previously calculated values would trigger the dirty flag on
steps even if the user didn't actually change anything. I (and
others) have wanted this fixed for many years.
This is a very dense commit that touches a core part of the
system. Hopefully the Changelog below helps.
* src/bucket/Bucket.js
(setValues): [BC-BREAK] Remove parameters `merge_index' and
`merge_null' parameters.
* src/bucket/DelayedStagingBucket.js
(setValues): [BC-BREAK] Remove `merge_index' and `merge_null
parameters. Remove distinction between `merge_index' and non-.
* src/bucket/QuoteDataBucket.js
(setValues): [BC-BREAK] Remove `merge_index' and `merge_null
parameters. Remove respective arguments from `_mergeData' call.
(_mergeData): Remove same parameters. Remove handling of
`merge_index' and `merge_null'.
(overwriteValues): Append `null' to each vector.
* src/bucket/StagingBucket.js
(_initState): Use `Object.create' instead of explicit prototype
instantiation (functionally equivalent).
(merge): Minor comment correction.
(_hasChanged): Rename to `_parseChanges'.
(_parseChanges): Rename from `_hasChanged'. Remove `merge_index'
parameter. Generate new object rather than mutation original
data (prevent dangerous and subtle bugs from side-effects). Clone
each vector rather than modifying/referencing directly (this was
previously done during merge). Remove `merge_index'
distinction. Handle non-terminating `null' values.
(setValues): [BC-BREAK] Remove `merge_index' and `merge_null'
parameters. Use new object generated by `_parseChanges'. Remove
cloning of each vector (`_parseChanges' now does that). Remove
`merge_index' distinction.
(overwriteValues): Remove argument to `setValues' call.
(getFilledDiff): [BC-BREAK] Use `_staged' rather than `_curdata'.
(commit): Remove second and third arguments of call to `setValues'
of underlying bucket.
* src/client/Client.js
(_initStepUi): Remove second argument of calls to quote `setData'.
* src/client/quote/ClientQuote.js
(setData): [BC-BREAK] Remove `merge_nulls' parameter. Remove second
and third arguments of call to staging bucket `setValues'. Add
comment indicating a long-standing problem with committing the
staging bucket contents before save has succeeded.
* src/server/request/DataProcessor.js
(processDiff): Remove `permit_null' argument of `sanitizeDiff'
call.
(sanitizeDiff): Remove `permit_null' parameter. Hard-code filter
call's `permit_null' argument to `true'.
(_determineDapiFields): Properly handle `null's (ignore) rather than
inadvertently converting them into the string "null".
* test/bucket/StagingBucketTest.js: Modify test cases
accordingly. Add tests to verify that updates and diffs operate
as expected, especially support for non-terminating `null's.
(createStubBucket): Use `QuoteDataBucket'. Ideally remove this
coupling in the future, but this is a more realistic test case for
the time being.
* test/server/request/DataProcessorTest.js: Update test to account for
hard-coded `given_null' argument.
A bit arbitrary, but it contains text that's coupled to the layout of
the UI, and it usually pushes the button down off of the bar.
* src/client/Client.js (_showLockedNotification): Remove end of
"unlock quote" string.
Copyright notices updated. More casual references to "LoVullo
Associates" replaced with "RT Specialty / Lovullo", which will be "RT
Specialty Buffalo" in the future. Or "RT Specialty", depending on how
this is rolled out. Or "Ryan Specialty Group". Who knows.
"R-T Specialty, LLC." is the legal name, which includes the dash. Not
to be confused with a certain television network.
I have sat on releasing a lot of this code for years because I wanted
the liza repo to be in a pristine state---tests and all---which
required a great deal of refactoring. Well, that never happened, and
time is up.
LoVullo Associates---my employer---has been purchased by another
company. This means that any agreement with LoVullo regarding
releasing free software is going to have to be re-negotiated with this
new company, and I have no idea how those negotiations will go. So,
I have no choice but to simply release everything in its current state,
or risk it being lost forever.
This represents work over the past 6--7 years, 99.9% of it written by
me. This project has been my baby for quite some time, and has been
through a number of battles with deadlines and other unfortunate
circumstances; the scars show. I also didn't really "know" JS when
starting this project. Perhaps you can help improve upon it.
There are some odds-and-ends that could be committed. And references
to insurance and LoVullo need to be removed to generalize this.
I hope that this will not be the last public commit for this project.
I'll fight the good fight and we'll see where that takes us. Maybe
it'll be easy.
Happy hacking.
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.
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.
Mike Gerwitz
Mike Gerwitz