Make editable implementations consistent.
Review Request #7908 — Created Jan. 25, 2016 and submitted
Sonar uses several custom x-editable types, for various things. These were done
with a mix of ES6 classes and$.extend
. I've changed it so they all use the
class-based implementation, and are consistent with regards to things like
EditableClass.defaults
.
Tested each of the editables and saw that they still worked.
Description | From | Last Updated |
---|---|---|
This wasn't needed before, it seems. Why is it needed now? |
mike_conley | |
I don't understand. Aren't we already defining this up in editable-datepicker? Should this be something that we just do once … |
mike_conley | |
Same as above regarding editableform... this looks like we're redefining this in three places. |
mike_conley |
-
This looks good to me - just a few questions.
-
lib/frontend/editable-epiceditor.js (Diff revision 1) This wasn't needed before, it seems. Why is it needed now?
-
lib/frontend/editable-epiceditor.js (Diff revision 1) I don't understand. Aren't we already defining this up in editable-datepicker? Should this be something that we just do once in a common place?
-
lib/frontend/editable-selectize.js (Diff revision 1) Same as above regarding editableform... this looks like we're redefining this in three places.
Change Summary:
Move buttons definitions out into another file.
Commit: |
|
||||
---|---|---|---|---|---|
Diff: |
Revision 2 (+125 -113) |
-
Tool: Pyflakes Ignored Files: lib/frontend/editable-epiceditor.js lib/frontend/editable-defs.js lib/frontend/editable-selectize.js lib/frontend/editable-datepicker.js lib/frontend/all-status-reports-view.js Tool: PEP8 Style Checker Ignored Files: lib/frontend/editable-epiceditor.js lib/frontend/editable-defs.js lib/frontend/editable-selectize.js lib/frontend/editable-datepicker.js lib/frontend/all-status-reports-view.js