Updates:
Status: Started
Comment #1 on issue 1878 by kpreid.switchb.org: Refactor repairES5
http://code.google.com/p/google-caja/issues/detail?id=1878
Here's what I'm envisioning doing:
* Kludge records grow an additional flag, "deferredCompletion" (or
something, lousy name). This causes them to not be counted in maxSeverity,
but to also be put in a list of not-yet-repaired-problems during the normal
repair phase.
* ses.ok() reports the maximum of maxSeverity and the severities of the
not-yet-repaired list. A different internal API is used for the "are we OK
enough to run the stages after repairES5" question that ses.ok is currently
used for.
* When startSES does its final check before clearing the dirty flag, it
tells the repairES5 module to run the tests for everything in
not-yet-repaired, which results in the list being emptied as tests pass.
(If we wanted to be paranoid, we could run _all_ kludge tests, too.)
I am also considering an additional more radical change: make repairES5.js,
like startSES.js, have no side effects when loaded, and instead provide a
function to invoke. This would make it possible to _test_ repairES5.js, by
providing an alternate kludge list. It would complicate the
build/standalone-invocation slightly by requiring another glue file like
hookupSES.js.
erights, what do you think of these proposed changes?
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
---
You received this message because you are subscribed to the Google Groups "Google Caja Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
