mediawiki-extensions-Visual.../modules/ve/ui/ve.ui.Surface.js

268 lines
6.7 KiB
JavaScript
Raw Normal View History

/*!
* VisualEditor UserInterface Surface class.
*
* @copyright 2011-2013 VisualEditor Team and others; see AUTHORS.txt
* @license The MIT License (MIT); see LICENSE.txt
*/
/**
* A surface is a top-level object which contains both a surface model and a surface view.
*
* @class
* @extends ve.Element
*
* @constructor
* @param {HTMLDocument|Array|ve.dm.LinearData|ve.dm.Document} data Document data to edit
* @param {Object} [config] Config options
*/
ve.ui.Surface = function VeUiSurface( dataOrDoc, config ) {
// Parent constructor
The Great ve.ui.Surface refactor of 2013 Prologue: Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't see you there! In a world where iframes are outlaws, and symbols like document and window are global, there were more than a few assumptions about which document or window was being used. But fear not - for this commit (probably) tracks them all down, leaving a trail of iframe-compatible awesomeness in its wake. With the great ve.ui.Surface now able to be used inside of iframes, let the reference editing commence. But there, lurking in the darkness is a DM issue so fierce it may take Roan and/or Ed up to 3 whole hours to sort it out. Note to Roan and/or Ed: Editing references seems to work fine, but when saving the page there are "no changes" which is a reasonable indication to the contrary. Objectives: * Make it possible to have multiple surfaces be instantiated, get along nicely, and be embedded inside of iframes if needed. * Make reference content editable within a dialog Approach: * Move what's left of ve.Editor to ve.ui.Surface and essentially obliterate all use of it * Make even more stuff inherit from ve.Element (long live this.$$) * Use the correct document or window anywhere it was being assumed to be the top level one * Resolve stacking order issues by removing the excessive use of z-index and introducing global and local overlay elements for each editor * Add a surface to the reference dialog, load up the reference contents and save them back on apply * Actually destroy what we create in ce and ui surfaces * Add recursive frame offset calculation method to ve.Element * Moved ve.ce.Surface's getSelectionRect method to the prototype Bonus: * Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it was separate in the first place, but I'm likely the one to blame) * Fix blatant lies in documentation * Whitespace cleanup here and there * Get rid of ve.ui.Window overlays - not used or needed Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
2013-05-20 22:45:50 +00:00
ve.Element.call( this, config );
// Mixin constructor
ve.EventEmitter.call( this, config );
// Properties
The Great ve.ui.Surface refactor of 2013 Prologue: Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't see you there! In a world where iframes are outlaws, and symbols like document and window are global, there were more than a few assumptions about which document or window was being used. But fear not - for this commit (probably) tracks them all down, leaving a trail of iframe-compatible awesomeness in its wake. With the great ve.ui.Surface now able to be used inside of iframes, let the reference editing commence. But there, lurking in the darkness is a DM issue so fierce it may take Roan and/or Ed up to 3 whole hours to sort it out. Note to Roan and/or Ed: Editing references seems to work fine, but when saving the page there are "no changes" which is a reasonable indication to the contrary. Objectives: * Make it possible to have multiple surfaces be instantiated, get along nicely, and be embedded inside of iframes if needed. * Make reference content editable within a dialog Approach: * Move what's left of ve.Editor to ve.ui.Surface and essentially obliterate all use of it * Make even more stuff inherit from ve.Element (long live this.$$) * Use the correct document or window anywhere it was being assumed to be the top level one * Resolve stacking order issues by removing the excessive use of z-index and introducing global and local overlay elements for each editor * Add a surface to the reference dialog, load up the reference contents and save them back on apply * Actually destroy what we create in ce and ui surfaces * Add recursive frame offset calculation method to ve.Element * Moved ve.ce.Surface's getSelectionRect method to the prototype Bonus: * Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it was separate in the first place, but I'm likely the one to blame) * Fix blatant lies in documentation * Whitespace cleanup here and there * Get rid of ve.ui.Window overlays - not used or needed Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
2013-05-20 22:45:50 +00:00
this.$globalOverlay = $( '<div>' );
this.$localOverlay = this.$$( '<div>' );
this.$localOverlayBlockers = this.$$( '<div>' );
this.$localOverlayControls = this.$$( '<div>' );
this.$localOverlayMenus = this.$$( '<div>' );
this.model = new ve.dm.Surface(
dataOrDoc instanceof ve.dm.Document ? dataOrDoc : new ve.dm.Document( dataOrDoc )
);
The Great ve.ui.Surface refactor of 2013 Prologue: Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't see you there! In a world where iframes are outlaws, and symbols like document and window are global, there were more than a few assumptions about which document or window was being used. But fear not - for this commit (probably) tracks them all down, leaving a trail of iframe-compatible awesomeness in its wake. With the great ve.ui.Surface now able to be used inside of iframes, let the reference editing commence. But there, lurking in the darkness is a DM issue so fierce it may take Roan and/or Ed up to 3 whole hours to sort it out. Note to Roan and/or Ed: Editing references seems to work fine, but when saving the page there are "no changes" which is a reasonable indication to the contrary. Objectives: * Make it possible to have multiple surfaces be instantiated, get along nicely, and be embedded inside of iframes if needed. * Make reference content editable within a dialog Approach: * Move what's left of ve.Editor to ve.ui.Surface and essentially obliterate all use of it * Make even more stuff inherit from ve.Element (long live this.$$) * Use the correct document or window anywhere it was being assumed to be the top level one * Resolve stacking order issues by removing the excessive use of z-index and introducing global and local overlay elements for each editor * Add a surface to the reference dialog, load up the reference contents and save them back on apply * Actually destroy what we create in ce and ui surfaces * Add recursive frame offset calculation method to ve.Element * Moved ve.ce.Surface's getSelectionRect method to the prototype Bonus: * Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it was separate in the first place, but I'm likely the one to blame) * Fix blatant lies in documentation * Whitespace cleanup here and there * Get rid of ve.ui.Window overlays - not used or needed Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
2013-05-20 22:45:50 +00:00
this.view = new ve.ce.Surface( this.model, this, { '$$': this.$$ } );
this.context = new ve.ui.Context( this, { '$$': this.$$ } );
this.dialogs = new ve.ui.WindowSet( this, ve.ui.dialogFactory );
The Great ve.ui.Surface refactor of 2013 Prologue: Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't see you there! In a world where iframes are outlaws, and symbols like document and window are global, there were more than a few assumptions about which document or window was being used. But fear not - for this commit (probably) tracks them all down, leaving a trail of iframe-compatible awesomeness in its wake. With the great ve.ui.Surface now able to be used inside of iframes, let the reference editing commence. But there, lurking in the darkness is a DM issue so fierce it may take Roan and/or Ed up to 3 whole hours to sort it out. Note to Roan and/or Ed: Editing references seems to work fine, but when saving the page there are "no changes" which is a reasonable indication to the contrary. Objectives: * Make it possible to have multiple surfaces be instantiated, get along nicely, and be embedded inside of iframes if needed. * Make reference content editable within a dialog Approach: * Move what's left of ve.Editor to ve.ui.Surface and essentially obliterate all use of it * Make even more stuff inherit from ve.Element (long live this.$$) * Use the correct document or window anywhere it was being assumed to be the top level one * Resolve stacking order issues by removing the excessive use of z-index and introducing global and local overlay elements for each editor * Add a surface to the reference dialog, load up the reference contents and save them back on apply * Actually destroy what we create in ce and ui surfaces * Add recursive frame offset calculation method to ve.Element * Moved ve.ce.Surface's getSelectionRect method to the prototype Bonus: * Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it was separate in the first place, but I'm likely the one to blame) * Fix blatant lies in documentation * Whitespace cleanup here and there * Get rid of ve.ui.Window overlays - not used or needed Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
2013-05-20 22:45:50 +00:00
this.commands = {};
this.enabled = true;
// Initialization
The Great ve.ui.Surface refactor of 2013 Prologue: Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't see you there! In a world where iframes are outlaws, and symbols like document and window are global, there were more than a few assumptions about which document or window was being used. But fear not - for this commit (probably) tracks them all down, leaving a trail of iframe-compatible awesomeness in its wake. With the great ve.ui.Surface now able to be used inside of iframes, let the reference editing commence. But there, lurking in the darkness is a DM issue so fierce it may take Roan and/or Ed up to 3 whole hours to sort it out. Note to Roan and/or Ed: Editing references seems to work fine, but when saving the page there are "no changes" which is a reasonable indication to the contrary. Objectives: * Make it possible to have multiple surfaces be instantiated, get along nicely, and be embedded inside of iframes if needed. * Make reference content editable within a dialog Approach: * Move what's left of ve.Editor to ve.ui.Surface and essentially obliterate all use of it * Make even more stuff inherit from ve.Element (long live this.$$) * Use the correct document or window anywhere it was being assumed to be the top level one * Resolve stacking order issues by removing the excessive use of z-index and introducing global and local overlay elements for each editor * Add a surface to the reference dialog, load up the reference contents and save them back on apply * Actually destroy what we create in ce and ui surfaces * Add recursive frame offset calculation method to ve.Element * Moved ve.ce.Surface's getSelectionRect method to the prototype Bonus: * Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it was separate in the first place, but I'm likely the one to blame) * Fix blatant lies in documentation * Whitespace cleanup here and there * Get rid of ve.ui.Window overlays - not used or needed Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
2013-05-20 22:45:50 +00:00
this.$
.addClass( 've-ui-surface' )
.append( this.view.$ );
this.$localOverlay
.addClass( 've-ui-surface-overlay ve-ui-surface-overlay-local' )
.append( this.$localOverlayBlockers )
.append( this.$localOverlayControls )
.append( this.$localOverlayMenus );
this.$localOverlayMenus
The Great ve.ui.Surface refactor of 2013 Prologue: Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't see you there! In a world where iframes are outlaws, and symbols like document and window are global, there were more than a few assumptions about which document or window was being used. But fear not - for this commit (probably) tracks them all down, leaving a trail of iframe-compatible awesomeness in its wake. With the great ve.ui.Surface now able to be used inside of iframes, let the reference editing commence. But there, lurking in the darkness is a DM issue so fierce it may take Roan and/or Ed up to 3 whole hours to sort it out. Note to Roan and/or Ed: Editing references seems to work fine, but when saving the page there are "no changes" which is a reasonable indication to the contrary. Objectives: * Make it possible to have multiple surfaces be instantiated, get along nicely, and be embedded inside of iframes if needed. * Make reference content editable within a dialog Approach: * Move what's left of ve.Editor to ve.ui.Surface and essentially obliterate all use of it * Make even more stuff inherit from ve.Element (long live this.$$) * Use the correct document or window anywhere it was being assumed to be the top level one * Resolve stacking order issues by removing the excessive use of z-index and introducing global and local overlay elements for each editor * Add a surface to the reference dialog, load up the reference contents and save them back on apply * Actually destroy what we create in ce and ui surfaces * Add recursive frame offset calculation method to ve.Element * Moved ve.ce.Surface's getSelectionRect method to the prototype Bonus: * Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it was separate in the first place, but I'm likely the one to blame) * Fix blatant lies in documentation * Whitespace cleanup here and there * Get rid of ve.ui.Window overlays - not used or needed Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
2013-05-20 22:45:50 +00:00
.append( this.context.$ );
this.$globalOverlay
.addClass( 've-ui-surface-overlay ve-ui-surface-overlay-global' )
.append( this.dialogs.$ );
// Make instance globally accessible for debugging
ve.instances.push( this );
};
/* Inheritance */
ve.inheritClass( ve.ui.Surface, ve.Element );
ve.mixinClass( ve.ui.Surface, ve.EventEmitter );
/* Events */
/**
ve.ui.Toolbar: Refactor floating logic for performance == Renamed methods == * enableFloating -> enableFloatable * disableFloating -> disableFloatable * setPosition -> float * resetPosition -> unfloat == Scroll and resize event == Timeline for scroll event reduced from about half a dozen "Recalculate style" and various forced "Paint" down to 0. New timeline for scroll is clean (for me: from ~35 to ~59 fps): * 1 Event (scroll) * 1 Composite Layer The composite layer action is the browser changing the viewport to a different portion of the document drawing. Exactly the one thing a simple scroll should do. Timeline for resize event is still pretty crowded and low fps, but it has improved. Further improvement would likely be around using requestAnimation and going outside ve.ui.Toolbar. == Changes == * New: ve.ui.Toolbar#initialize. Similar to what surface has. Users of Toolbar should decide whether to call enableFloatable, append it to the DOM at some point and then call initialize() once. * Don't compute offset() every time. Eliminated by doing it once in #initialize. These 'top' and 'left' offsets do not change. * Don't compute outerWidth() and $window.width() every time. Reduced by doing it once in #initialize to compute the 'right' offset. Updating it only on resize. * Don't set 'top' every time. This is already in the stylesheet. It was never set to anything else so the abstraction for it in #float has been removed. This also made it obvious that code for "ve-ui-toolbar-bottom" was unused and left behind. Tha class was only ever being removed from something (never added). The one addClass call for it was in a condition that is always false ("if top > 0"). * Don't set 'left' every time. Eliminated by doing it once in #float. * Don't set 'right' every time. Reduced by no longer doing it on scroll. Done once in #float, and on resize after computing the new value for it. * Remove no-op style operations. Wrapped methods in if-floatable, if-floated etc. to reduce a fair amount of easily avoided re-paint overhead. * Avoid double re-paint in mw.ViewPageTarget. Though we prevent a lot of redundant re-paints now, whenever we do repaint we want to do it in 1 repaint instead of 2. ve.ui.Toolbar emits #toolbarPosition, which tells mw.ViewPageTarget to update toolbarTracker which would read the new $bar style properties and copy them over to the $toolbarTracker. However, this read operation forces the browser to do an immediate re-paint half-way just for $bar. Browsers only repaint when style properties are changed and JS has yielded. The exception to this is JS reading style properties: in that case the browser is forced to do those deferred repaints directly and reflect the new values. We can avoid this double repaint by passing the updated values as data instead of requiring the receiver to read the DOM (and thus a keep the deferred repaint). Now toolbarTracker can use them directly whilst the browser hasn't even repainted $bar yet. == Clean up == * Redundant "border-radius: 0". This would reset something, but it never does. None of the things it inherits from set a border-radius. There is one subclass where toolbar is used with a border-radius (".ve-ui-surfaceWidget .ve-ui-toolbar-bar" sets a border-radius) which overrides this on purpose, so the default of 0 is redundant. * Pattern "if ( .. ) addClass() else removeClass()" changed to: "toggleClass( , .. )" Bug: 52014 Change-Id: I9be855148962eee068a77fe83e98eb20bbdcfeec
2013-07-25 02:36:01 +00:00
* Whenever the toolbar $bar position is updated, the changes that took place.
*
* @event toolbarPosition
* @param {jQuery} $bar Toolbar bar
ve.ui.Toolbar: Refactor floating logic for performance == Renamed methods == * enableFloating -> enableFloatable * disableFloating -> disableFloatable * setPosition -> float * resetPosition -> unfloat == Scroll and resize event == Timeline for scroll event reduced from about half a dozen "Recalculate style" and various forced "Paint" down to 0. New timeline for scroll is clean (for me: from ~35 to ~59 fps): * 1 Event (scroll) * 1 Composite Layer The composite layer action is the browser changing the viewport to a different portion of the document drawing. Exactly the one thing a simple scroll should do. Timeline for resize event is still pretty crowded and low fps, but it has improved. Further improvement would likely be around using requestAnimation and going outside ve.ui.Toolbar. == Changes == * New: ve.ui.Toolbar#initialize. Similar to what surface has. Users of Toolbar should decide whether to call enableFloatable, append it to the DOM at some point and then call initialize() once. * Don't compute offset() every time. Eliminated by doing it once in #initialize. These 'top' and 'left' offsets do not change. * Don't compute outerWidth() and $window.width() every time. Reduced by doing it once in #initialize to compute the 'right' offset. Updating it only on resize. * Don't set 'top' every time. This is already in the stylesheet. It was never set to anything else so the abstraction for it in #float has been removed. This also made it obvious that code for "ve-ui-toolbar-bottom" was unused and left behind. Tha class was only ever being removed from something (never added). The one addClass call for it was in a condition that is always false ("if top > 0"). * Don't set 'left' every time. Eliminated by doing it once in #float. * Don't set 'right' every time. Reduced by no longer doing it on scroll. Done once in #float, and on resize after computing the new value for it. * Remove no-op style operations. Wrapped methods in if-floatable, if-floated etc. to reduce a fair amount of easily avoided re-paint overhead. * Avoid double re-paint in mw.ViewPageTarget. Though we prevent a lot of redundant re-paints now, whenever we do repaint we want to do it in 1 repaint instead of 2. ve.ui.Toolbar emits #toolbarPosition, which tells mw.ViewPageTarget to update toolbarTracker which would read the new $bar style properties and copy them over to the $toolbarTracker. However, this read operation forces the browser to do an immediate re-paint half-way just for $bar. Browsers only repaint when style properties are changed and JS has yielded. The exception to this is JS reading style properties: in that case the browser is forced to do those deferred repaints directly and reflect the new values. We can avoid this double repaint by passing the updated values as data instead of requiring the receiver to read the DOM (and thus a keep the deferred repaint). Now toolbarTracker can use them directly whilst the browser hasn't even repainted $bar yet. == Clean up == * Redundant "border-radius: 0". This would reset something, but it never does. None of the things it inherits from set a border-radius. There is one subclass where toolbar is used with a border-radius (".ve-ui-surfaceWidget .ve-ui-toolbar-bar" sets a border-radius) which overrides this on purpose, so the default of 0 is redundant. * Pattern "if ( .. ) addClass() else removeClass()" changed to: "toggleClass( , .. )" Bug: 52014 Change-Id: I9be855148962eee068a77fe83e98eb20bbdcfeec
2013-07-25 02:36:01 +00:00
* @param {Object} update
* @param {boolean} [update.floating] Whether the toolbar is in floating mode
* @param {Object} [update.css] One or more css properties that changed
* @param {Object} [update.offset] Updated offset object (from jQuery.fn.offset, though
* it also includes `offset.right`)
*/
/* Methods */
ve.ui.Surface.prototype.initialize = function () {
this.view.$.after( this.$localOverlay );
The Great ve.ui.Surface refactor of 2013 Prologue: Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't see you there! In a world where iframes are outlaws, and symbols like document and window are global, there were more than a few assumptions about which document or window was being used. But fear not - for this commit (probably) tracks them all down, leaving a trail of iframe-compatible awesomeness in its wake. With the great ve.ui.Surface now able to be used inside of iframes, let the reference editing commence. But there, lurking in the darkness is a DM issue so fierce it may take Roan and/or Ed up to 3 whole hours to sort it out. Note to Roan and/or Ed: Editing references seems to work fine, but when saving the page there are "no changes" which is a reasonable indication to the contrary. Objectives: * Make it possible to have multiple surfaces be instantiated, get along nicely, and be embedded inside of iframes if needed. * Make reference content editable within a dialog Approach: * Move what's left of ve.Editor to ve.ui.Surface and essentially obliterate all use of it * Make even more stuff inherit from ve.Element (long live this.$$) * Use the correct document or window anywhere it was being assumed to be the top level one * Resolve stacking order issues by removing the excessive use of z-index and introducing global and local overlay elements for each editor * Add a surface to the reference dialog, load up the reference contents and save them back on apply * Actually destroy what we create in ce and ui surfaces * Add recursive frame offset calculation method to ve.Element * Moved ve.ce.Surface's getSelectionRect method to the prototype Bonus: * Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it was separate in the first place, but I'm likely the one to blame) * Fix blatant lies in documentation * Whitespace cleanup here and there * Get rid of ve.ui.Window overlays - not used or needed Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
2013-05-20 22:45:50 +00:00
$( 'body' ).append( this.$globalOverlay );
this.view.initialize();
// By re-asserting the current selection and forcing a poll we force selection to be something
// reasonable - otherwise in Firefox, the initial selection is (0,0), causing bug 42277
this.model.getFragment().select();
this.view.surfaceObserver.poll();
this.model.startHistoryTracking();
};
/**
* Check if editing is enabled.
*
* @method
* @returns {boolean} Editing is enabled
*/
ve.ui.Surface.prototype.isEnabled = function () {
return this.enabled;
};
/**
* Get the surface model.
*
* @method
* @returns {ve.dm.Surface} Surface model
*/
ve.ui.Surface.prototype.getModel = function () {
return this.model;
};
/**
* Get the surface view.
*
* @method
* @returns {ve.ce.Surface} Surface view
*/
ve.ui.Surface.prototype.getView = function () {
return this.view;
};
/**
* Get the context menu.
*
* @method
* @returns {ve.ui.Context} Context user interface
*/
ve.ui.Surface.prototype.getContext = function () {
return this.context;
};
/**
The Great ve.ui.Surface refactor of 2013 Prologue: Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't see you there! In a world where iframes are outlaws, and symbols like document and window are global, there were more than a few assumptions about which document or window was being used. But fear not - for this commit (probably) tracks them all down, leaving a trail of iframe-compatible awesomeness in its wake. With the great ve.ui.Surface now able to be used inside of iframes, let the reference editing commence. But there, lurking in the darkness is a DM issue so fierce it may take Roan and/or Ed up to 3 whole hours to sort it out. Note to Roan and/or Ed: Editing references seems to work fine, but when saving the page there are "no changes" which is a reasonable indication to the contrary. Objectives: * Make it possible to have multiple surfaces be instantiated, get along nicely, and be embedded inside of iframes if needed. * Make reference content editable within a dialog Approach: * Move what's left of ve.Editor to ve.ui.Surface and essentially obliterate all use of it * Make even more stuff inherit from ve.Element (long live this.$$) * Use the correct document or window anywhere it was being assumed to be the top level one * Resolve stacking order issues by removing the excessive use of z-index and introducing global and local overlay elements for each editor * Add a surface to the reference dialog, load up the reference contents and save them back on apply * Actually destroy what we create in ce and ui surfaces * Add recursive frame offset calculation method to ve.Element * Moved ve.ce.Surface's getSelectionRect method to the prototype Bonus: * Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it was separate in the first place, but I'm likely the one to blame) * Fix blatant lies in documentation * Whitespace cleanup here and there * Get rid of ve.ui.Window overlays - not used or needed Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
2013-05-20 22:45:50 +00:00
* Get dialogs window set.
*
* @method
The Great ve.ui.Surface refactor of 2013 Prologue: Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't see you there! In a world where iframes are outlaws, and symbols like document and window are global, there were more than a few assumptions about which document or window was being used. But fear not - for this commit (probably) tracks them all down, leaving a trail of iframe-compatible awesomeness in its wake. With the great ve.ui.Surface now able to be used inside of iframes, let the reference editing commence. But there, lurking in the darkness is a DM issue so fierce it may take Roan and/or Ed up to 3 whole hours to sort it out. Note to Roan and/or Ed: Editing references seems to work fine, but when saving the page there are "no changes" which is a reasonable indication to the contrary. Objectives: * Make it possible to have multiple surfaces be instantiated, get along nicely, and be embedded inside of iframes if needed. * Make reference content editable within a dialog Approach: * Move what's left of ve.Editor to ve.ui.Surface and essentially obliterate all use of it * Make even more stuff inherit from ve.Element (long live this.$$) * Use the correct document or window anywhere it was being assumed to be the top level one * Resolve stacking order issues by removing the excessive use of z-index and introducing global and local overlay elements for each editor * Add a surface to the reference dialog, load up the reference contents and save them back on apply * Actually destroy what we create in ce and ui surfaces * Add recursive frame offset calculation method to ve.Element * Moved ve.ce.Surface's getSelectionRect method to the prototype Bonus: * Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it was separate in the first place, but I'm likely the one to blame) * Fix blatant lies in documentation * Whitespace cleanup here and there * Get rid of ve.ui.Window overlays - not used or needed Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
2013-05-20 22:45:50 +00:00
* @returns {ve.ui.WindowSet} Dialogs window set
*/
The Great ve.ui.Surface refactor of 2013 Prologue: Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't see you there! In a world where iframes are outlaws, and symbols like document and window are global, there were more than a few assumptions about which document or window was being used. But fear not - for this commit (probably) tracks them all down, leaving a trail of iframe-compatible awesomeness in its wake. With the great ve.ui.Surface now able to be used inside of iframes, let the reference editing commence. But there, lurking in the darkness is a DM issue so fierce it may take Roan and/or Ed up to 3 whole hours to sort it out. Note to Roan and/or Ed: Editing references seems to work fine, but when saving the page there are "no changes" which is a reasonable indication to the contrary. Objectives: * Make it possible to have multiple surfaces be instantiated, get along nicely, and be embedded inside of iframes if needed. * Make reference content editable within a dialog Approach: * Move what's left of ve.Editor to ve.ui.Surface and essentially obliterate all use of it * Make even more stuff inherit from ve.Element (long live this.$$) * Use the correct document or window anywhere it was being assumed to be the top level one * Resolve stacking order issues by removing the excessive use of z-index and introducing global and local overlay elements for each editor * Add a surface to the reference dialog, load up the reference contents and save them back on apply * Actually destroy what we create in ce and ui surfaces * Add recursive frame offset calculation method to ve.Element * Moved ve.ce.Surface's getSelectionRect method to the prototype Bonus: * Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it was separate in the first place, but I'm likely the one to blame) * Fix blatant lies in documentation * Whitespace cleanup here and there * Get rid of ve.ui.Window overlays - not used or needed Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
2013-05-20 22:45:50 +00:00
ve.ui.Surface.prototype.getDialogs = function () {
return this.dialogs;
};
/**
The Great ve.ui.Surface refactor of 2013 Prologue: Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't see you there! In a world where iframes are outlaws, and symbols like document and window are global, there were more than a few assumptions about which document or window was being used. But fear not - for this commit (probably) tracks them all down, leaving a trail of iframe-compatible awesomeness in its wake. With the great ve.ui.Surface now able to be used inside of iframes, let the reference editing commence. But there, lurking in the darkness is a DM issue so fierce it may take Roan and/or Ed up to 3 whole hours to sort it out. Note to Roan and/or Ed: Editing references seems to work fine, but when saving the page there are "no changes" which is a reasonable indication to the contrary. Objectives: * Make it possible to have multiple surfaces be instantiated, get along nicely, and be embedded inside of iframes if needed. * Make reference content editable within a dialog Approach: * Move what's left of ve.Editor to ve.ui.Surface and essentially obliterate all use of it * Make even more stuff inherit from ve.Element (long live this.$$) * Use the correct document or window anywhere it was being assumed to be the top level one * Resolve stacking order issues by removing the excessive use of z-index and introducing global and local overlay elements for each editor * Add a surface to the reference dialog, load up the reference contents and save them back on apply * Actually destroy what we create in ce and ui surfaces * Add recursive frame offset calculation method to ve.Element * Moved ve.ce.Surface's getSelectionRect method to the prototype Bonus: * Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it was separate in the first place, but I'm likely the one to blame) * Fix blatant lies in documentation * Whitespace cleanup here and there * Get rid of ve.ui.Window overlays - not used or needed Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
2013-05-20 22:45:50 +00:00
* Get the context menu.
*
* @method
The Great ve.ui.Surface refactor of 2013 Prologue: Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't see you there! In a world where iframes are outlaws, and symbols like document and window are global, there were more than a few assumptions about which document or window was being used. But fear not - for this commit (probably) tracks them all down, leaving a trail of iframe-compatible awesomeness in its wake. With the great ve.ui.Surface now able to be used inside of iframes, let the reference editing commence. But there, lurking in the darkness is a DM issue so fierce it may take Roan and/or Ed up to 3 whole hours to sort it out. Note to Roan and/or Ed: Editing references seems to work fine, but when saving the page there are "no changes" which is a reasonable indication to the contrary. Objectives: * Make it possible to have multiple surfaces be instantiated, get along nicely, and be embedded inside of iframes if needed. * Make reference content editable within a dialog Approach: * Move what's left of ve.Editor to ve.ui.Surface and essentially obliterate all use of it * Make even more stuff inherit from ve.Element (long live this.$$) * Use the correct document or window anywhere it was being assumed to be the top level one * Resolve stacking order issues by removing the excessive use of z-index and introducing global and local overlay elements for each editor * Add a surface to the reference dialog, load up the reference contents and save them back on apply * Actually destroy what we create in ce and ui surfaces * Add recursive frame offset calculation method to ve.Element * Moved ve.ce.Surface's getSelectionRect method to the prototype Bonus: * Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it was separate in the first place, but I'm likely the one to blame) * Fix blatant lies in documentation * Whitespace cleanup here and there * Get rid of ve.ui.Window overlays - not used or needed Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
2013-05-20 22:45:50 +00:00
* @returns {ve.ui.Context} Context user interface
*/
The Great ve.ui.Surface refactor of 2013 Prologue: Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't see you there! In a world where iframes are outlaws, and symbols like document and window are global, there were more than a few assumptions about which document or window was being used. But fear not - for this commit (probably) tracks them all down, leaving a trail of iframe-compatible awesomeness in its wake. With the great ve.ui.Surface now able to be used inside of iframes, let the reference editing commence. But there, lurking in the darkness is a DM issue so fierce it may take Roan and/or Ed up to 3 whole hours to sort it out. Note to Roan and/or Ed: Editing references seems to work fine, but when saving the page there are "no changes" which is a reasonable indication to the contrary. Objectives: * Make it possible to have multiple surfaces be instantiated, get along nicely, and be embedded inside of iframes if needed. * Make reference content editable within a dialog Approach: * Move what's left of ve.Editor to ve.ui.Surface and essentially obliterate all use of it * Make even more stuff inherit from ve.Element (long live this.$$) * Use the correct document or window anywhere it was being assumed to be the top level one * Resolve stacking order issues by removing the excessive use of z-index and introducing global and local overlay elements for each editor * Add a surface to the reference dialog, load up the reference contents and save them back on apply * Actually destroy what we create in ce and ui surfaces * Add recursive frame offset calculation method to ve.Element * Moved ve.ce.Surface's getSelectionRect method to the prototype Bonus: * Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it was separate in the first place, but I'm likely the one to blame) * Fix blatant lies in documentation * Whitespace cleanup here and there * Get rid of ve.ui.Window overlays - not used or needed Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
2013-05-20 22:45:50 +00:00
ve.ui.Surface.prototype.getCommands = function () {
return this.commands;
};
/**
* Destroy the surface, releasing all memory and removing all DOM elements.
*
* @method
* @returns {ve.ui.Context} Context user interface
*/
ve.ui.Surface.prototype.destroy = function () {
ve.instances.splice( ve.instances.indexOf( this ), 1 );
this.$.remove();
The Great ve.ui.Surface refactor of 2013 Prologue: Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't see you there! In a world where iframes are outlaws, and symbols like document and window are global, there were more than a few assumptions about which document or window was being used. But fear not - for this commit (probably) tracks them all down, leaving a trail of iframe-compatible awesomeness in its wake. With the great ve.ui.Surface now able to be used inside of iframes, let the reference editing commence. But there, lurking in the darkness is a DM issue so fierce it may take Roan and/or Ed up to 3 whole hours to sort it out. Note to Roan and/or Ed: Editing references seems to work fine, but when saving the page there are "no changes" which is a reasonable indication to the contrary. Objectives: * Make it possible to have multiple surfaces be instantiated, get along nicely, and be embedded inside of iframes if needed. * Make reference content editable within a dialog Approach: * Move what's left of ve.Editor to ve.ui.Surface and essentially obliterate all use of it * Make even more stuff inherit from ve.Element (long live this.$$) * Use the correct document or window anywhere it was being assumed to be the top level one * Resolve stacking order issues by removing the excessive use of z-index and introducing global and local overlay elements for each editor * Add a surface to the reference dialog, load up the reference contents and save them back on apply * Actually destroy what we create in ce and ui surfaces * Add recursive frame offset calculation method to ve.Element * Moved ve.ce.Surface's getSelectionRect method to the prototype Bonus: * Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it was separate in the first place, but I'm likely the one to blame) * Fix blatant lies in documentation * Whitespace cleanup here and there * Get rid of ve.ui.Window overlays - not used or needed Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
2013-05-20 22:45:50 +00:00
this.$globalOverlay.remove();
this.$localOverlay.remove();
this.view.destroy();
};
/**
* Disable editing.
*
* @method
*/
ve.ui.Surface.prototype.disable = function () {
this.view.disable();
this.model.disable();
this.enabled = false;
};
/**
* Enable editing.
*
* @method
*/
ve.ui.Surface.prototype.enable = function () {
this.enabled = true;
this.view.enable();
this.model.enable();
};
/**
* Execute an action or command.
*
* @method
* @param {ve.ui.Trigger|string} action Trigger or symbolic name of action
* @param {string} [method] Action method name
* @param {Mixed...} [args] Additional arguments for action
* @returns {boolean} Action or command was executed
*/
ve.ui.Surface.prototype.execute = function ( action, method ) {
The Great ve.ui.Surface refactor of 2013 Prologue: Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't see you there! In a world where iframes are outlaws, and symbols like document and window are global, there were more than a few assumptions about which document or window was being used. But fear not - for this commit (probably) tracks them all down, leaving a trail of iframe-compatible awesomeness in its wake. With the great ve.ui.Surface now able to be used inside of iframes, let the reference editing commence. But there, lurking in the darkness is a DM issue so fierce it may take Roan and/or Ed up to 3 whole hours to sort it out. Note to Roan and/or Ed: Editing references seems to work fine, but when saving the page there are "no changes" which is a reasonable indication to the contrary. Objectives: * Make it possible to have multiple surfaces be instantiated, get along nicely, and be embedded inside of iframes if needed. * Make reference content editable within a dialog Approach: * Move what's left of ve.Editor to ve.ui.Surface and essentially obliterate all use of it * Make even more stuff inherit from ve.Element (long live this.$$) * Use the correct document or window anywhere it was being assumed to be the top level one * Resolve stacking order issues by removing the excessive use of z-index and introducing global and local overlay elements for each editor * Add a surface to the reference dialog, load up the reference contents and save them back on apply * Actually destroy what we create in ce and ui surfaces * Add recursive frame offset calculation method to ve.Element * Moved ve.ce.Surface's getSelectionRect method to the prototype Bonus: * Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it was separate in the first place, but I'm likely the one to blame) * Fix blatant lies in documentation * Whitespace cleanup here and there * Get rid of ve.ui.Window overlays - not used or needed Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
2013-05-20 22:45:50 +00:00
var trigger, obj, ret;
if ( !this.enabled ) {
return;
}
if ( action instanceof ve.ui.Trigger ) {
trigger = action.toString();
The Great ve.ui.Surface refactor of 2013 Prologue: Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't see you there! In a world where iframes are outlaws, and symbols like document and window are global, there were more than a few assumptions about which document or window was being used. But fear not - for this commit (probably) tracks them all down, leaving a trail of iframe-compatible awesomeness in its wake. With the great ve.ui.Surface now able to be used inside of iframes, let the reference editing commence. But there, lurking in the darkness is a DM issue so fierce it may take Roan and/or Ed up to 3 whole hours to sort it out. Note to Roan and/or Ed: Editing references seems to work fine, but when saving the page there are "no changes" which is a reasonable indication to the contrary. Objectives: * Make it possible to have multiple surfaces be instantiated, get along nicely, and be embedded inside of iframes if needed. * Make reference content editable within a dialog Approach: * Move what's left of ve.Editor to ve.ui.Surface and essentially obliterate all use of it * Make even more stuff inherit from ve.Element (long live this.$$) * Use the correct document or window anywhere it was being assumed to be the top level one * Resolve stacking order issues by removing the excessive use of z-index and introducing global and local overlay elements for each editor * Add a surface to the reference dialog, load up the reference contents and save them back on apply * Actually destroy what we create in ce and ui surfaces * Add recursive frame offset calculation method to ve.Element * Moved ve.ce.Surface's getSelectionRect method to the prototype Bonus: * Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it was separate in the first place, but I'm likely the one to blame) * Fix blatant lies in documentation * Whitespace cleanup here and there * Get rid of ve.ui.Window overlays - not used or needed Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
2013-05-20 22:45:50 +00:00
if ( trigger in this.commands ) {
return this.execute.apply( this, this.commands[trigger] );
}
} else if ( typeof action === 'string' && typeof method === 'string' ) {
// Validate method
if ( ve.ui.actionFactory.doesActionSupportMethod( action, method ) ) {
// Create an action object and execute the method on it
obj = ve.ui.actionFactory.create( action, this );
ret = obj[method].apply( obj, Array.prototype.slice.call( arguments, 2 ) );
return ret === undefined || !!ret;
}
}
return false;
};
The Great ve.ui.Surface refactor of 2013 Prologue: Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't see you there! In a world where iframes are outlaws, and symbols like document and window are global, there were more than a few assumptions about which document or window was being used. But fear not - for this commit (probably) tracks them all down, leaving a trail of iframe-compatible awesomeness in its wake. With the great ve.ui.Surface now able to be used inside of iframes, let the reference editing commence. But there, lurking in the darkness is a DM issue so fierce it may take Roan and/or Ed up to 3 whole hours to sort it out. Note to Roan and/or Ed: Editing references seems to work fine, but when saving the page there are "no changes" which is a reasonable indication to the contrary. Objectives: * Make it possible to have multiple surfaces be instantiated, get along nicely, and be embedded inside of iframes if needed. * Make reference content editable within a dialog Approach: * Move what's left of ve.Editor to ve.ui.Surface and essentially obliterate all use of it * Make even more stuff inherit from ve.Element (long live this.$$) * Use the correct document or window anywhere it was being assumed to be the top level one * Resolve stacking order issues by removing the excessive use of z-index and introducing global and local overlay elements for each editor * Add a surface to the reference dialog, load up the reference contents and save them back on apply * Actually destroy what we create in ce and ui surfaces * Add recursive frame offset calculation method to ve.Element * Moved ve.ce.Surface's getSelectionRect method to the prototype Bonus: * Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it was separate in the first place, but I'm likely the one to blame) * Fix blatant lies in documentation * Whitespace cleanup here and there * Get rid of ve.ui.Window overlays - not used or needed Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
2013-05-20 22:45:50 +00:00
/**
* Add all commands from initialization options.
*
* @method
* @param {string[]|Object[]} commands List of symbolic names of commands in the command registry
*/
ve.ui.Surface.prototype.addCommands = function ( commands ) {
var i, len, command;
for ( i = 0, len = commands.length; i < len; i++ ) {
command = ve.ui.commandRegistry.lookup( commands[i] );
if ( !command ) {
throw new Error( 'No command registered by that name: ' + commands[i] );
}
this.addTriggers( [ve.ui.triggerRegistry.lookup( commands[i] )], command );
}
};
/**
* Add triggers to surface.
*
* @method
* @param {ve.ui.Trigger[]} triggers Triggers to associate with command
* @param {Object} command Command to trigger
*/
ve.ui.Surface.prototype.addTriggers = function ( triggers, command ) {
var i, len, trigger;
for ( i = 0, len = triggers.length; i < len; i++ ) {
// Normalize
trigger = triggers[i].toString();
// Validate
if ( trigger.length === 0 ) {
throw new Error( 'Incomplete trigger: ' + triggers[i] );
}
this.commands[trigger] = command.action;
}
};
/**
* Surface 'dir' property (GUI/User-Level Direction)
* @returns {string} 'ltr' or 'rtl'
*/
ve.ui.Surface.prototype.getDir = function () {
return this.$.css( 'direction' );
};