closes#2426, closes#2781, closes#2913
- Concatenate vendor files on change of js in core/shared/
- Add all the markerManager stuff to its own mixin
- make markers a shared object for all that mix it in. makes it easier to use helper functions in different modules
- add getMarkdown method, returns object with two keys holding the markdown: one with markers, the other without
- Clear markers when codemirror is destroyed
- make Editor subcomponents communicate through the Editor Controller
- Set Codemirror and html preview shared scrolling
- Set CodeMirror, html preview css scroll class with util
- Create 'scratch' property in Editor controller; prevents a model save wiping image markers due to markdown bindings
- Add editor and html preview actions to handle img upload start/finish
- disable codemirror when an image is being uploaded, enables on success or failure
- Fix editor wordcount when there are 0 words
- Add modal dialog when transitioning out of the editor with an unsaved post
- Add window.onbeforeunload handling with `.unloadDirtyMessage()` on editor controller
- and various other things
resolves#2416
This is a pretty large commit but what it's adding are pretty fundamental to the admin app.
- Creates top level actions on the ApplicationRoute for opening and closing modals. This allows sending the 'openModal' action from any template to open a modal.
- Every modal template lives in 'templates/modals/{{modalName}}'
- Each modal can have a backing controller of the same name that can provide additional control for that modal. Those controllers reside in 'controllers/modals/{{modalName}}'
- Created the ModalDialog component which is where all the logic for the component resides. It's not at 100% parity with the existing Ghost modal system but it has the foundation for further fleshing out. It currently accepts parameters for styling how the modal should appear, which previously was defined in JS files in the Backbone admin.
- This creates the 'delete all posts', 'delete this post', 'markdown', and 'upload' modal. Some are in more stages of completion than others, but I wanted to just get the foundation in place as fast as possible.
- This also creates the UploadModal component which is a subclass of the ModalDialog component. The reason for this subclassing is that the UploadModal component directly accesses the DOM and when that occurs in Ember it should remain in a component definition. It's ready for extending to reach parity. Note: depending on needs the base ModalDialog class may need to be modified.
