[PATCH][CCLA]: Provide 'Print' plugin for Editor

[Jared Jurkiewicz]

Next in the series of plugins I've been working on for Editor. This is one for adding a 'Print' button to the toolbar. This plugin is not much code and implements printing the contents of the editor iFrame.

The Print Plugin provides the following:
1.) Print support for FireFox? 2, 3, 3.5, Safari 3+, Chrome 2+, Opera 9.6+
2.) Icon for Print button (enabled and disabled).
3.) When pressed, it just makes use of the normal browser print dialog.

Notes:

---

Included is a basic test for Print. Since Print invokes the print dialog, it is not suitable for use with DOH Robot (Not to mention you don't want the robot suddenly printing pages on you!)

The CSS and NLS 'Command' are in separate files currently to make this easy to test standalone, but if accepted, these should be merged into the base editor ones (which I'll do once you're happy with it).

Browsers I've tested on during its development have been: FireFox? 2, FireFox? 3, FireFox? 3.5, Opera 9.6, Internet Explorer 7.0, 6.0, and 8.0, as well as Safari 3.2.3 and Chrome 2.0.

I'd like to get this into Dojo 1.4.

[bill]

Looks good. The only thing I'm wondering about is the hack here:

_initButton: function(){
	...
	this.editor.commands[this.command] = strings["print"];
	this.inherited(arguments);
	delete this.command; // kludge so setEditor doesn't make the button invisible

I've seen this in your other plugins too. The root problem is that queryCommandEnabled() and thus _Plugin.setEditor() are only designed for built-in commands to the editor. Note that queryCommandEnabled() is only working for toggleDir etc. because it has code for those plugins even though it really shouldn't.

What I'm wondering is if it could be less hacky by just defining setEditor() yourself, and avoiding that code in _Plugin.js altogether.

I'm attaching a version of Print.js that does that. Seems to be working fine and I think it reduced the code size some.

Oh, also, about this code:

//Set up a check that we have a print function
//and disable button if we do not.
this.editor.onLoadDeferred.addCallback(
	dojo.hitch(this, function(){
		if(!this.editor.iframe.contentWindow["print"]){
			this.button.attr("disabled", true);
		}
	})
);

When is it that there's no print capability? When the computer hasn't been configured w/a printer? BTW you could save a few bytes by saying this.button.attr("disabled", !this.editor.iframe.contentWindow["print"]); (and avoiding the if statement) but it doesn't matter much.

[bill]

override setEditor() to avoid hacks

[Jared Jurkiewicz]

The print check is for cases where the browser doesn't provide a print function on the window. This is possible to occur (though it is unlikely), so there's a chekc there that disables print if the browser in question doesn't seem to support the ability.

[Jared Jurkiewicz]

Updated plugins as per Bill's comments.

[Jared Jurkiewicz]

Okay, I updated the plugin based off your suggestions. I also uncovered a quirk with Opera that I fixed (I need to clone the stylesout of the editor iframe over to the clone doc so they print right. Mainly helps with the dojox.editor.plugins.PageBreak? plugin. If you think it's good, I'll merge the NLS into dijit's editor NLS, merge the icons and css, then check in.

[bill]

OK looks good.

It's unfortunate opera weighs us down so much but at least it's not code in dijit/_base etc. Editor is expected to be big so it's not so bad. I assume the "problem"/security thing you are talking about is still true for Opera 10, which was just released production?

Oh, I would put the this.editor.onLoadDeferred.addCallback() into setEditor() since theoretically speaking one plugin instance could be applied to multiple editors (although we aren't actively testing and supporting that ability).

[Jared Jurkiewicz]

(In [20072]) Adding in simple 'Print' plugin to editor. fixes #9777